language.future.{noStringPlus,syntax} #5235
Conversation
|
I'm sympathetic to the idea, but I think this piecemeal introduction of language options and settings does more harm than good:
|
|
@soc I think you're saying, why are there two mechanisms for An implicit However, I haven't looked at whether the backend gets to do something efficient with The operators that haven't been mentioned are the primitive It's called |
|
Also I don't mind if it's called add or plus, I just want it to not compile :) |
|
@dwijnand My concern about how it's encoded was that an implicit wrapper might not be completely eliminated. Also, I learned on Scala-JS it's just plus. https://issues.scala-lang.org/browse/SI-9784 |
|
Interesting. |
| * at the end of the typechecking run for the enclosing unit. This | ||
| * is done to avoid potential cyclic reference errors by implicits | ||
| * that are forced too early. | ||
| * @param isAnOptInFeature Indicates if the feature is opt-in or not |
There was a problem hiding this comment.
this isn't what the parameter is called anymore
|
@som-snytt feel free to fold my commit if you'd like |
|
@dwijnand no way, it's your fault this ball got rolling! Besides, it already has a green check. |
|
I'm sorry that we were not able to give this the review/discussion attention it deserved, but I unfortunately don't think we can include this in 2.12.0. It's an exciting addition to the feature flags, but the design space is big enough to warrant some more exploration. As a compromise, I propose we do this exploration under a -Y flag in 2.12.x and, once baked, SIP it and expose it as a feature flag in 2.13. |
Conflicts: src/compiler/scala/tools/nsc/typechecker/Typers.scala
The multichoice setting wildcard behaves like import syntax. Using `-language:_` enables all unprefixed feature settings, and `-language:experimental._` enables the experimental ones. For simplicity, we only exploit one level of nesting. This allows `-language:future._` settings which should not be automatically enabled under `-language:_`.
For controlling future syntax changes.
som-snytt
force-pushed
the
topic/language-future
branch
from
057ee47 to
a531d68
Compare
|
/rebuild |
|
As I said, I'm open to a 2.12.x PR that introduces a -Y flag to experiment with this, but ultimately the full solution will require a SIP and a 2.13 target. |
|
OK, thanks, a lot of old girlfriends said that and I wish I'd listened when my wife said it would need a sip and a different target. I'll ask @dwijnand and the other haters of plus co-optation if this is worth pushing forward. |
|
I don't have the hate or bandwidth necessary atm. Looked for someone on twitter https://twitter.com/dwijnand/status/834556490866389002 |
|
Instead of removing |
7 participants
Something like that.
This has
-language:-future.noStringPlusenable local implicit, whereString.+is not installed but is tacked on when typecheck fails, on the conservative theory that extra implicit searches for string concat would hurt compilation time for status quo. But that theory is not tested, so maybe there's no reason to be conservative.