Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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
Someone should register @elidable. I'm only allowed one free account and would rather buy coffee a few times a month.
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.
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
Off to practice "Für Elisible" now.