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