Why are there no short-circuiting compound assignment operators `&&=` and `||=`?

[Peter Lawrey]

Hi,
  I would add you can write

b = b && something()
b = b || something()

I suspect we only have as many assignment operators as we do because C had
them. The most useful is += the rest don't add much IMHO.

In terms of budget, another key resource is how much developers will
remember and use effectively. Java assumes a lower budget requirement in
this regard, which I believe is part of it's popularity. Personally I have
a fairly high tolerance for complexity but most developers benefit from the
language being as simple as possible.

Regards Peter.

On Mon, 10 Aug. 2020, 22:53 Brian Goetz, <brian.goetz at oracle.com> wrote:

>
>
> > https://stackoverflow.com/q/2324549/ shows that there is interest in
> having these operators and there
> > are no clear arguments why they don't exist yet.
> > The question is therefore: Has the JDK team discussed adding these
> operators in the past and if so
> > what where the reasons against adding them?
>
> I'm not aware of any specific discussion on this particular issue, but
> if someone were to propose it, the answer would likely be: it's not an
> unreasonable request, but it doesn't carry its weight.
>
> "Carrying its weight" needs to be judged by its costs and benefits, and
> by its cost-benefit ratio relative to other candidate features.
>
> I think you are implicitly assuming (by the phrase "there is interest")
> that the cost is near zero and the benefit is greater than zero, so it
> seems an obvious win.  But this belies an incorrect understanding of
> cost; a feature like this affects the language spec, the implementation,
> the JCK, and every IDE and Java textbook. There are no trivial language
> features.  And the benefit, while nonzero, is pretty small.
>
> Secondarily, there are infinitely many features we _could_ do, but we
> only have capacity to do a handful every few years (and users have a
> limited capacity to absorb new features.)  So we have to be very careful
> as to which we pick, as each feature (even a trivial-seeming one)
> consumes some of this budget, and invariably takes it away from others.
> It's not "why not this feature", but "what other features will we not do
> (or delay) so we can do this one, and is that a good trade?"  And I
> can't really imagine this being a good trade against anything else we're
> working on.
>
> So, it clears the bar of "not a terrible idea" (which is already pretty
> good, a lot of feature requests don't even clear that), but seems
> unlikely to ever clear the bar of "a better use of our evolution budget
> than anything else."
>