http://wiki.dlang.org/DIP25

[via Digitalmars-d]

On Monday, 29 December 2014 at 20:42:37 UTC, Dicebot wrote:
> On Monday, 29 December 2014 at 20:20:45 UTC, Steven 
> Schveighoffer wrote:
>> But this precludes doing anything with a mutable t inside foo, 
>> since inout means "const within the function".
>
> Hm, yes, this is indeed quite the problem. I have totally 
> forgot that compiler has no means of figuring out which 
> invocation of inout is currently used.
>
> But something very similar feels necessary to me. There is 
> constness, lifetime, purity - inventing new dedicated keyword 
> for each case does not feel like scaling approach. Especially 
> when existing one is named so generic.

I've been pondering this for a while, maybe someone with a better 
theoretical foundation has an answer...

These concepts you mention (I'd add "type erasure", because 
that's what `inout` is currently about) are inter-connected and 
have some overlap with each other. But at the same time, they are 
still separate concepts.

Do you think they are just aspects of one all-encompassing Grand 
Unified Concept? Because if they turn out to be fundamentally 
separate, they are better treated as such, instead of mixing them 
up. Dedicated keywords may be the way to go if this is the case. 
(From what I've seen so far, I think they are indeed separate, 
but who knows?)

In general, I get the impression from both DIP25 and DIP69 that 
both are motivated by minimizing the change to the existing 
language, instead of looking for the most powerful solution (that 
may have other use-cases besides the ones under consideration). 
I.e., instead of asking which concepts are behind the problem in 
question, how these concepts could be expressed in an ideal 
world, and then making compromises to fit them into D, it seems 
like we're starting with some premises (as few changes as 
possible, no type modifiers), and then look for a solution that 
needs to sacrifice the smallest number of use cases to stay 
within the constraints. This is particularly bad if our premises 
are going against the nature of the problem we want to solve, 
because then we are guaranteed to get a bad solution.