On 16-Nov-2015 19:44, Steven Schveighoffer wrote:
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.
inout should be indistinguishable of const but the moment you pass
inout(T) to a template it becomes murky.
Appender!(inout(int)) - which qualifier to instantiate?
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.
Looks a lot like tail-const problem. That is immutable T!E has no way to
convert to T!(immutable E) and similarly to T!(const E).
Overall I see const/immutable a fine thing at low-level scope but not
applicable at all to high-level constructs.
If something is conceptually const - its the task of implementation
which may rely on physical const qualifier somewhere deep inside.
-Steve
--
Dmitry Olshansky
