simon_o

12 ms·

91.
by simon_o 9y ago
I don't think you can get away with that for theoretical and practical reasons: 1. There is a ton of code out there which does something like def contains(that: Thing): Boolean = this.value identity that || this.value equal
92.
by simon_o 9y ago
That's pretty much saying "it is the way it is", which a) is not even true, see floating point numbers and b) will be obsolete with value types. Needless to say, there is pointless confusion created by Java's design, and
93.
by simon_o 9y ago
Just off the top of my head, esoteric additions: - "Numeric harmonization" which makes some of the existing issues with implicit numeric conversions even worse. - Multiversal equality, which adds even more special rules to the imp
94.
by simon_o 9y ago
Which ones would you remove?
95.
by simon_o 9y ago
There are also specs for later versions, it's just that they are pretty outdated and unmaintained. (Like pretty much everything related to documentation.) I think Jetbrains has some experience using that spec to implement the IDE'
96.
by simon_o 9y ago
That's the whole point of what Scala is doing. Allow flexibility to support such requirements later on, without forcing people to break source and binary compatibility, unlike in Java, C# etc. That's the reason why you can e. g. i
97.
by simon_o 9y ago
This seems to be a poorly writen article for various reasons: > The grapheme has an intermediate position between letter and ligature. It might have been a ligature in the past, but it is definitely not a ligature today. A ligature is a
98.
by simon_o 9y ago
It's kind of hard to get developers to adopt Scala for Android, when people in charge are diametrically opposed to even acknowledge its existence. :-)