Closed soronpo closed 6 years ago
I hit this issue when I implemented prefix types in SIP33, and I fixed it by placing the PrefixType
in CompoundType
.
/** {{{
* CompoundType ::= PrefixType
* | AnnotType {with AnnotType} [Refinement]
* | Refinement
* }}}
*/
/** {{{
* PrefixType ::= [`-' | `+' | `~' | `!'] SimpleType
* }}}
*/
PrefixType
can easily handle the special case for a literal type in SimpleType
, and fix this issue (similarly to what is done for expressions).
I don't know if it's the best way to fix this. I can add SIP23 to my branch and let you know if its fixed, if you're interested.
I can add SIP23 to my branch and let you know if its fixed, if you're interested. That would be very helpful ... thank you :-)
Nb. there are conflicts with 2.13.x which are resolved on my as-yet-not pushed branch.
@milessabin I took your topic/sip-23-redux and added SIP33. This issue is fixed, and can viewed at https://github.com/soronpo/scala/tree/sips23%2B33
Oops. Forgot to push the commit to the branch. Now the branch is updated.
This issue is fixed by SIP33? That's great ... I think it makes sense to deal with it there ... thanks for that :-)
The issue is fixed thanks to the prefix type implementation part of the SIP. However, after watching yesterday's SIP meeting, I think that eventually the prefix types will not be accepted and only the infix precedence part will. I think I know now how to modify your SIP23 implementation, to fix this bug. I will provide you with a branch today.
That'd be great ... thanks again :-)
Here is the branch https://github.com/soronpo/scala/tree/sips23fix
Notice that this is not just an implementation fix, but a Spec fix (should be fixed in the SIP proposal as well). Also notice that it allows 2 ~~ -2
but not 2 ~~ +2
. The latter can be easily supported of course, if you think it should.
@soronpo I'm not quite sure I understand the relationship between the commit in that branch and SIP-33. Are you saying that it's the part which was rejected by the SIP committee? If that's the case then I think I'd prefer to defer this until after SIP-23 is accepted, which will in any make the case for SIP-33 in it's entirety a lot more compelling.
The fix was a private case when implementing prefix types in SIP33. Now the branch I have provided just fixes the issue for SIP23 without supporting prefix types. The committee has not rejected anything yet, but requested that the SIP would be split into two (it combined a change to infix type precedence as well). The members also mentioned that they are skeptical that prefix types would be accepted. In any case, prefix types are only truly usable with literal types, so indeed SIP23 is a must for prefix types to make sense.
Do you have a strong feeling in favour of including that in SIP-23 or would you be happy to defer it until after SIP-23 is accepted?
@soronpo I've taken a closer look at your two SIPs, and I think I'd prefer not to have them coupled with SIP-23 ... I think that if we can get SIP-23 agreed on it will make it a lot easier to motivate both your two SIPs.
I think that it would make sense to deal with the syntax issue for negated numeric literals, but the crucial point here is that they aren't type operators in any substantial sense: the type -2
is atomic in same sense the that the term -2
is.