On 7/20/15 8:07 PM, Max Klimov wrote:
On Monday, 13 July 2015 at 13:50:02 UTC, Steven Schveighoffer wrote:
With inout, it's even more tricky, because the compiler has to ensure
it's not inout when it leaves the function. And it's not possible in
some cases to do this.
You can simply use a template function without hand-written cases.
This is what inout was meant to replace.
Sure, however, it is still not the same as using inout.
Firstly, your function should be instantiated somewhere for mutable T,
const T and immutable T. Otherwise, compilation errors will be postponed
until the code usage.
Sure, you can do this via unit tests.
Secondly, template function can not be virtual.
Unfortunately, this is true. I don't know how this could be fixed, and
inout certainly does help in this regard.
I'm wondering why it is needed to have special casting rules and other
restrictions for inout if people should treat inout as wildcard for
mutable, immutable and const.
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.
As far as I can imagine, a compiler should
generate one single object code for inout function. Is it possible just
to check validity of an inout(T) function for T, const(T) and
immutable(T) and then, if success, generate the code? (keeping in mind
that you can execute another inout functions inside this one). Am I
missing something?
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.
-Steve
