simon_o

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 equality that

Pretty much every single collection implementation would be broken if this stopped working with value types. Additionally, you would run into issues with floating point numbers which would not be found/retrieved anymore if identity were removed.

2.

The idea to define a _sane_ definition of identity/equality across all types is there to avoid the "next-best" option: boxing primitives to wrapper classes which is both slow and has terrible semantics.

3.

I don't really think restricting identity to e.g. reference types makes sense given that equality is defined for every type. Either none of them should be available by default, or both should be.

There _are_ multiple valid ways to compare to things (consider floating point numbers for a second) and making one more privileged than the other feels wrong.

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 there are better approaches available.

All you have to do is to adapt the semantic model from reference equality vs. value equality to identity vs. equality.

Identity checks whether the "bits" are identical, irregardless of whether the bits are "references" or values, and equality is a user-defined operation.

    "Foo" equality "Foo" // True
    "Foo" identity "Foo" // Only true if they point to the same "object"
    123 equality 123 // True
    123 identity 123 // True
    Double.NaN equality Double.NaN // False
    Double.NaN identity Double.NaN // True

Which symbols you pick for "equality" and "identity" is largely arbitrary.

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 implicit resolution algorithm, complicates the mental model of the language, is either extremely invasive or severely limited when applied to real-code, and falls apart when dealing with existing language features of Scala like variance.

- Addition of inline, which has absolutely no reason to be a new keyword.

- The tentative idea of adding T? for T|Null (as it appeared on some slides) which makes it obvious that no thought has been given to how the lessons of handling nulls apply to Scala.

Then we have enums, which are just poorly designed and executed, repeat the mistakes made with both case classes and scala.Enumeration, do not address the problems it is supposed to solve, fail to address actually valid existing problems, all while introducing not one, but two additional syntactic constructs which are unlike anything we had before.

On top of that we got incompatible additions in minor releases of 2.12:

- Additional places where commas can be added, which ignores one of the most common complaints about Scala: Too many syntactic variations to express the same thing.

- The addition of @showAsInfix which is a solution in search of a problem.

But at least unsound type projections got restricted, I guess. (That's the only major thing I can think of that will have a larger impact...)

Probably the removal of forSome and cleaning up existentials?

Which ones would you remove?

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's Scala typechecker. Long story short: years later, it still doesn't work.

I would be kind of concerned about the esoteric new features they added to Dotty, looks like the lesson has not been learned yet.

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. implement or override a def with a val.

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 purely typographical device that is completely interchangeable with the non-ligature variant. This is not the case with ß.

> It behaves as a ligature in that it has no separate position in the alphabet.

Not having a separate position is not sufficient evidence that it is a ligature. ä, ö, ü also don't have separate positions when ordering stuff.

> It also has no traditional capital form (although some type designers have introduced forms of "capital ß" de facto).

It had the same traditional from for almost 130 years. Yes, there are a few stylistic variations on the traditional forms, as well as some early experiments trying something completely different which have never been widely adopted.

> It behaves like a letter [...]

It is a letter, just like w is a letter, not a vv ligature.

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. :-)