Generic operator overloading for immutable types?

[ag0aep6g via Digitalmars-d-learn]

On 06/14/2017 03:47 AM, Steven Schveighoffer wrote:
> The fundamental difference is that const and immutable share a 
> characteristic that mutable doesn't -- you can't mutate the data.

(... through the reference at hand.)

const and mutable share this: The data may be mutated from elsewhere.

Mutable shares as much with const as immutable does. But it's the other 
side of const, of course.

> The reason const(inout) works is because const(immutable) evaluates to 
> just immutable.
> 
> const(<mutable>) just evaluates to const. In this way, mutable is less 
> "special" than immutable.

Yeah. That makes it impossible to express the proposed type. But it's 
just because of the immutable > const > mutable progression in D, which 
makes for arbitrary asymmetries between mutable and immutable.

If it were const > mutable = immutable (and if we had a `mutable` 
keyword), then `inout immutable` would work like today's `inout const`, 
`inout mutable` would be what I'm talking about, and `inout const` would 
just be the same as const.

That's not going to happen, of course. It would break everything. And 
I'm sure there are many obvious issues that I'm just ignoring here 
because the thing won't happen anyway. But it would make `inout foo` 
more symmetric.

[...]
> The soundness of the function above seems good, but I don't know how to 
> reason about the return type of f. Because mutable has no type modifier, 
> it's hard to imagine doing this without one. And any time I think about 
> how to define it, it breaks down. I can't imagine const(blah(T)) 
> evaluating to mutable, no matter what blah is called, or how it works.
> 
> Literally the ONLY place this would be useful is for inout functions, 
> and Andrei pretty much has declared that inout should be completely 
> stricken from Phobos/druntime in favor of templates. I can't imagine any 
> leeway for another type modifier.
> 
> const(inout) literally was an afterthought observation that we could 
> relax the rules for this one case and get a little more usability.

Ok, I think we're in agreement. The described variant of inout would 
make sense, but isn't possible in D. It would be very awkward to 
implement the feature without changing how mutability qualifiers 
interact. And changing that would be way too disruptive. It's also not 
at all clear that it would go well with the rest of the language.