• Quirin Schroll (29/29) Dec 08 2023 There’s a discussion of head-const, i.e. `const`, but only the

Quirin Schroll <qs.il.paperinik gmail.com> writes:

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 

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.