Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Elidable categories #11825

Open
som-snytt opened this issue Dec 10, 2019 · 2 comments
Open

Elidable categories #11825

som-snytt opened this issue Dec 10, 2019 · 2 comments
Labels
Milestone

Comments

@som-snytt
Copy link

@som-snytt som-snytt commented Dec 10, 2019

-Xelide-below is only a single knob. What if I want to elide logging, assertions in my collections library, expensive checks, on different timetables? This is similar to warning output control, where categories associated with code sites can be elevated or suppressed.

Wouldn't it be useful if you could also specify the @elidable level independently for each assertion, because maybe some of them are really computationally expensive and acceptable to remove at runtime, and some of them aren't?

Also, wouldn't it be great if for all these assertions, the code expression is contained in the error message, so that when you don't have access to the source code, it's still possible to understand what went wrong when you input invalid values?

Issue forked from #9838

@SethTisue SethTisue added this to the Backlog milestone Dec 10, 2019
@hrhino

This comment has been minimized.

Copy link
Member

@hrhino hrhino commented Dec 10, 2019

Can we bring back "elisible"? I was looking for that method recently and couldn't find it. I was going to make a joke about UK v. US spellings, but Google tells me I'm probably thinking of "eligible" or Hindi. (I just realized that in writing "UK v. US" I need to make a choice whether to use the UK or the US spelling of "v[.]". I chose the latter out of Dotty solidarity, but that obvious pun is getting old quickly).

I like all of these suggestions but they assume I want to make these choices at compile time. We're in the amazing new world of JDK 1.7+; why don't we emit assert(...) as a call to a bootstrap method that either runs the assertion or does nothing. We could piggyback on LMF so we wouldn't even need to load the condition in the latter case.

Someone should register @elidable. I'm only allowed one free account and would rather buy coffee a few times a month.

@som-snytt

This comment has been minimized.

Copy link
Author

@som-snytt som-snytt commented Dec 10, 2019

I think Java's assert also says they should be enabled and not removed. Maybe in that context, removed also means edited or commented out.

There could be other interesting use cases for elided methods besides diagnostics, such as for implementing stubs, or not implementing them. @stub def magic(): Int = ??? elides to zero.

The use case for compile time is that as a build manager, I want to lock down the behavior before I deploy, without flags or config or -Dproduction.

Off to practice "Für Elisible" now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.