Persistent list
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Mon Nov 16 08:44:42 PST 2015
On 11/14/15 3:42 AM, Dmitry Olshansky wrote:
> On 14-Nov-2015 02:10, Andrei Alexandrescu wrote:
>> * Lines 141-152: I couldn't make tail() work with inout. Generally I'm
>> very unhappy about inout. I don't know how to use it. Everything I read
>> about it is extremely complicated compared to its power. I wish we
>> removed it from the language and replaced it with an understandable
>> idiom.
>>
>
> I can't agree more. Every time dealing with inout when I finally think I
> grok how it works the next instant I see that it doesn't do what I expect.
>
> For me inout inevitably stops at the boundary of being unnable to have
> List!(inout(T)) and the like.
One thing we could allow is types that contain inout member variables,
but ONLY in the context of inout functions. In other words, you can
create a type for it, but can only use it in the context of an inout
function.
A List!(inout(T)) outside an inout function has no meaning. This is why
we disallowed it.
However, my belief is that it's the lack of a mechanism to apply an
attribute to the tail of some struct that prevents the most utility
here. If you returned a List!(inout(T)) there is no way to magically
convert it to a List!(const(T)) or List!(immutable(T)).
Consider that Node in this code has a "const(Node)* next" as its tail.
I believe we should be able to achieve both.
-Steve
More information about the Digitalmars-d
mailing list