Persistent list

[Meta via Digitalmars-d]

On Tuesday, 17 November 2015 at 01:49:05 UTC, Steven 
Schveighoffer wrote:
> I think it's quite clear that inout in its current form is a 
> point of huge confusion. I want to work to fix this perception 
> (and fix the broken corners of the implementation).
>
> What I would ask is for those who at the moment dislike it keep 
> an open mind, and hold back on your pitchforks. I need to 
> prepare a suitable defense, and it's difficult to shake off the 
> "confusing and complex" albatross without having sufficient 
> time to create something that is easy to understand/explain for 
> something that is conceptually simple, but requires a complex 
> proof.
>
> What I am afraid of is that someone makes a decision that 
> something is bad, and by the time a good defense, or workable 
> proposal is mounted, the answer is "we already discussed that, 
> it's bad. Let's move on."
>
> At least with this, we have a feature that is part of the 
> language, so is unlikely to go away. But I'd hate to see a mob 
> of PR requests that remove inout from all of phobos/druntime 
> before I can counter this.
>
> I think inout is worth saving, it needs a few tweaks and a good 
> explanation.
>
> -Steve

Regarding my question on StackOverflow, I understand that I had 
an inaccurate picture of how inout works, which was causing my 
problem. These are also problems with const and immutable to a 
degree. However, inout is like a fourth qualifier that you have 
to deal with that is separate from const and immutable, due to 
how it currently works. In that light, I still don't think it 
pulls its weight. What user will have the presence of mind to 
define their Foobar type with an inout/const/immutable toString 
function? Almost none, and so Nullable!Foobar.opEquals cannot be 
inout. I first encountered this problem trying to get 
Nullable.toString to work with inout, and couldn't. That's my 
main gripe with inout.