Comment by rcoveson | Hacker News Reader

Comment by rcoveson | Hacker News Reader

Parent Full thread

> We could have unsigned integers but we're choosing not to because on the whole their disadvantages outweigh their advantages.

You (collectively) have this wrong; C, C++, C#, Rust, Go, et al. have it right. As long as we're just stating our beliefs outright instead of justifying them, that is. (That's not a request to justify your opinion; I'm sure it's been argued to death already.)

> security experts quite simply vetoed adding string interpolation as it's just too dangerous

Laughable. In an alternate universe where it didn't already exist, this could have been a JEP for StringBuilder and they would have vetoed that too.

> As to `STR.` -- which you won't need to use most of the time

Except for when you're trying to... make a String? Which is what ~everybody who ever asked for string interpolation in Java wanted to do?

What year would you estimate it will be when, at the average Java job, I can expect that most of the library APIs available to me which were often invoked with the form `func(String.format(...))` will have similar APIs that behave as JEP 430 template processors? Maybe after it's been full release for 3 years? 2, optimistically? Because during those years, in order to use this thing at all, people will be using `STR."\{}"`

Maybe you're right, but I think it's not so much a matter of what's right or wrong, but what's appropriate for languages with different audience size. Our experience is at evolving a language for a certain audience size, and perhaps if Java's popularity declines to the more modest market shares of the languages you mentioned, their choices may become appropriate for Java, too.

As to your other points, like I explained to someone else here, even three decades of experience evolving a language that's achieved a measure of success is still no guarantee that every feature will work well, which is why most big new features, string templates included, are first released as preview (i.e. a feature that may change). That allows us to test our hypotheses against the problems people actually encounter rather than those we or others may speculate they'd encounter, and adjust the feature accordingly before it is finalised. To the best of my knowledge, all preview features have undergone some adjustment before becoming permanent, but usually the changes required were relatively small.

Also, we try to think more long-term, because in ten years no one is going to care or even remember if a feature arrived five or seven years prior.

The problem with unsigned is the ridiculous underflow behavior. Unsigned integers are inherently unsafe without underflow checking at runtime. When you are using signed integers for a positive number, then seeing a negative number tells you everything you need to know (the program is wrong and it will most likely crash soon). However, when you are using unsigned to mean a number that can never be negative, then you can't just expect people to never underflow it even just to -1 because it will turn into a large positive number by accident. There is a semantic gap between the meaning of the type and what invariants it guarantees at runtime and that means having no unsigned integers is better for most code unless the unsigned Integer is fully underflow checked at runtime.

> unless the unsigned Integer is fully underflow checked at runtime.

Sure. That doesn't mean the datatype wouldn't be nice to have even with such checks. There are languages out there that fully check over- and underflow. Java could too.

I think you are confused. Unsigned arithmetic is modular. Unsigned integers are both positive and negative.

0b1111_1111 is congruent to both -1 and 255 (mod 256). We simply choose the value 255 as being the principle value for coercions, but you could equally well choose -1.

Is 3pm tomorrow or yesterday? Yes.

Unsigned != non-negative.

My favorite example of this was the major outage at a Swedish futures exchange in 2012 where the system wound up treating an unsigned order quantity as "negative" and placed an order for 4 billion futures contracts: https://www.reuters.com/article/markets-sweden-bug-idUSL5E8M...

Java still sits very close to JVM byte code, which is typed - adding unsigned ints would duplicate a huge deal of instructions.

So this feature has to wait for primitive classes, where it can be as simple as

  primitive class unsigned {
    int value;
  }

(Though it would need operator overloading to be used as a+b, which is not really liked in Java designer niches (with many good reasons against it) :D )

There is exactly one good reason against operator overloading, and that’s operator<<. People are mostly sane otherwise and it’s a good thing to have.

Arbitrary overloading can be problematic, like !#< or whatever is quite hard to look up (scala, haskell), but I agree that implementing an interface/trait that will give you that syntactic sugar is mostly okay (like Rust, e.g. implements Add would give you + operator).

I remember working in some scala that used akka actors and seeing ! for the first time. Something like:

  actor ! someData

It was just an operator to send the data to the actor. A named function would have been so much better.

Just take the operator overloading from Ceylon which has been designed to only allow mathematical use cases and harder to abuse for anything else. When you see an expression a + b it might not be two numbers but it will most likely be associative, distributive and commutative.

A lot of seemingly primitive Java syntax already expands to method calls: autoboxing, string conversions, string concatenation. Similarly, primitive arithmetic operators on unsigned integers could expand to calls to the corresponding Integer.{compare,divide,remainder,...}Unsigned methods. The compiler would turn these back into single machine instructions anyway. This would not need any new bytecode instructions.

Sure, though I do think that the currently existing rift between the primitive and object world should be healed first, to not leave behind another construct that will only be a backwards compatibility hindrance later.

(If I’m not mistaken, the existing unsigned functions already compile down to efficient machine code, so in the meanwhile that works)

Reply on news.ycombinator.com