Inout unclearness

Max Klimov via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 21 22:52:45 PDT 2015


On Tuesday, 21 July 2015 at 12:53:37 UTC, Steven Schveighoffer 
wrote:
> Again, it has nothing to do with code generation, it has to do 
> with type conversion. The compiler doesn't know how to convert 
> Rebindable!(inout(T)) to something that can be returned from an 
> inout function. We haven't figured out how to tell it what to 
> do there, so it has to give up.

So the way that I see it is that "inout" is preserved until code 
generation. For example, Rebindable can keep inout(T) in the 
internals. Then "inout" should be replaced by compiler with 3 
versions of type (const, mutable, immutable) for a check. Then 
the code will be generated one time. One of the problems here is 
that, for example, Rebindable!(const(T)) can be specialized and 
have different behavior, unlike Rebindable(inout(T)) for the case 
inout(T) = const(T).

> It has to not only successfully generate code, the code itself 
> has to be exactly the same for all 3 versions (and actually, if 
> you have multiple inout parameters, it potentially has to run 
> 3^parameter tests). It could potentially do this, but inout 
> works just as effectively with the current rules. It still does 
> not provide a way to convert a struct with an inout member to a 
> struct without one.

Yes, the code itself will be the same, I meant just checks.
3^n possible checks -- that is an excellent point, can be a 
problem (as well as several other possible problems that I didn't 
take into account).
Finally, I'm sure that there are a lot of reasons to make inout 
in the present way and I can accept it (regardless of the fact 
that inout doesn't fit now for cases more complex than trivial 
ones). Of course, it would be great if D type system is perfect 
some day :)




More information about the Digitalmars-d mailing list