undefined | Better HN

0 pointspron7d ago0 comments

> the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types.

Then you didn't read the JEP draft (it's not an accepted JEP) carefully. It says, under "future work":

Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.

In other words, the draft already incorporates your point, but JEPs (both drafts and actual JEPs) follow the pattern we've found to work so well, that features are best delivered piecemeal rather than in a big bang.

Having said that, I don't know the current plans for this matter, as that document is only in Draft status, so saying it's good or bad is pointless, as it's not even a proposal yet, just something being explored.

0 comments

3 comments · 1 top-level

stickfigure7d ago· 2 in thread

It's a proposal for a proposal, fine. Consider this my proposed feedback.

I don't think this syntax is desirable as currently proposed, and that one line under "future work" is doing far too much lifting. My sincere hope is that there are people closer to the process that also feel this way, they will provide similar feedback, and the next draft will be something completely different.

pronOP7d ago

Except we like delivering features by pieces, so unless your proposal is to first deliver global flags with no instance-specific control and later add more control (and I think you're not suggesting that), I don't see any difference between what you're suggesting and what that draft is suggesting. That a one-line under "future work" is doing a lot of lifting is just how we usually do it (and it's okay, people always complain, but we've tried the big-bang approach and this one just works better for us).

So consider that draft as an idea for how the site-specific nullability annotations could work rather than an idea for how nullability could work in the language in general.

stickfigure5d ago

> how the site-specific nullability annotations could work

That's fine but it's still a bad choice. The problem is that it defaults to everything nullable and adds noise for non-nullable. This is backwards; in the overwhelming majority of software that people use Java for, non-null is the common case and nullability is the exception.

Kotlin and Typescript got this right. Nobody wants! to! write code! like! this! And they won't, so the feature won't get used and we're back to everything being nullable.

1 more reply

j / k navigate · click thread line to collapse