Where head-const shines
Quirin Schroll
qs.il.paperinik at gmail.com
Fri Dec 8 11:59:13 UTC 2023
There’s a discussion of head-const, i.e. `const`, but only the
first layer of indirection, conversely to D’s transitive `const`,
here and there. I never understood the real deal because
head-const doesn’t really bring much to the table in terms of
guarantees.
As of lately, I had to code some Java, which I hadn’t done in
many years. Java lacks many things, but it has IMO two nice
things going for it: It’s type system, which I’m not really
discussing here, and how closures work.
**In Java, to capture a variable in a closure, it must be
`final`, i.e. head-const.**
It’s simple, but genius. Java’s closures capture by value. That
would be really bad if the programmer were to mutate a captured
value and expect the effect to be visible to the context, but it
isn’t. D, like many languages, has the capture-in-a-loop problem.
C++’s solution is to let the user decide about how to capture; if
something doesn’t work as intended, it’s on you. C# makes a
decision for you that you might not agree with or surprise you.
Java likewise makes a decision for you, but it won’t surprise you.
For capturing values, head-const really shines. If D required
`const`, it would ask for too much. In Java, `final` is
essentially what a storage class is in D, a property of a
variable *next to* its type, not *part of* its type. For
head-const in D, it would have to be a type constructor because
the pointer to a head-const value must retain that information.
While one could go all-in and make it `const`, that would overly
restrict the type.
I’m not proposing to add head-const to D. I just wanted to share
a little thing I learned recently.
More information about the Digitalmars-d
mailing list