Hacker News Reader

Comment by logicchains | Hacker News Reader

>One usage pattern many of us have found useful in our software for years is the "set once and only once" (singleton-ish)

C# has this: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

View on HN

> C# has this:

This is only syntactic sugar to allow using object initializers to initialize specific member varabiles of a class instance instead of simply using a constructor and/or setting member variables in follow-up statements. It's hardly the feature OP was describing.

While mutation of init-only properties is sometimes done by e.g. serializers through private reflection or unsafe accessors, it otherwise can lead to unsound behavior if class implementation does not expect this. You cannot bypass this through normal language means.

Same applies to readonly instance fields.

Where does "syntax sugar" end and "true features" begin?

Anyway, trying to actually prevent a program from modifying its own memory is really hopeless, right? So any promises beyond “syntactic sugar” would be resting on a poor foundation, perhaps even dangerously misleading.

You can always mmap a memory range, place a struct there, then mprotect it. And on the language side you cannot overwrite readonly structs observed by readonly refs (aside from unsafe, which will trigger segfault in this case).

There are ways to do it. What matters is the user ergonomics, otherwise, by this logic, most higher-level languages would have even less of a claim to immutability, and yet somehow it's not an issue?

If there are exotic requirements - there are exotic tools for it. FWIW static readonlys are blocked from modification even through reflection and modifying their memory with unsafe is huge UB.

That's new since I've been tramping around VS.NET (F# 2 or 3 & C# from 10ya).

My immediate purposes require that I avoid depending on unique programming language/environment constructions, but it helps to learn, so thanks for levelling me up.

And Java will soon have StableValue: https://openjdk.org/jeps/8312611

Reading the JEP, isn’t StableValue about JIT constants?

In .NET it’s just 'static readonly'.

The basic feature set is at-most-once thread-safe initialization of values, which can then enjoy the same constant folding and other JIT optimizations one would get from `static final`, but can be initialized at any point during the program's run.

  Non-goals
  It is not a goal to provide Java language support for declaring stable values.

Hmmm

From context, I would infer that this means they are not changing the Java language itself. It’s a feature expressed through the existing language, like as a library feature. I could be wrong though.

Yes you're correct, the idea is that they're not adding any keywords or bytecodes, just some new standard lib APIs that will get some special treatment by the JVM.

Reply on news.ycombinator.com