Meta via Digitalmars-d
digitalmars-d at puremagic.com
Mon Nov 16 17:11:28 PST 2015
On Tuesday, 17 November 2015 at 00:30:39 UTC, Steven
> The problem it solves is to provide a mechanism that allows one
> to safely apply the same qualifiers to the return type, but
> have the inputs be constant *throughout the function*.
> A templated function doesn't do this, you can have conditional
> code, or unchecked method calls that can modify the data when
> Of course, if this isn't important, then the template solution
> is usable. My take is that whenever you use inout is when you
> would normally use const, but const doesn't allow what you
> need. If your function doesn't need const inside the function,
> then you shouldn't use inout.
> To me, it feels like inout is simple, but the implementation
> has warts that make it seem inconsistent. There is also the
> issue that nested inout is super-confusing, because now you
> have layers of inout, each layer meaning possibly something
> different. If we could somehow fix the nested part (and allow
> types with inout members inside there), I think inout would be
> less intimidating.
I don't mean to derail this thread, but I also am not really
crazy about inout in its current form. Its transitive nature is
one issue (though that can't be changed due to const and
immutable also being transitive), but also the fact that inout is
basically a fourth qualifier, which causes a lot of pain when
you're wrapping other types.
For example, calling opEquals on a wrapped struct inside the
opEquals of the wrapper struct (which is marked as inout) when
the wrapped struct does not also define an inout opEquals, will
not call the mutable opEquals of the wrapped struct. It *will
not* compile unless the wrapped struct also defines an inout
opEquals, no matter the constness of the wrapper or the wrappee.
Basically, wrapper types cannot with inout.
More information about the Digitalmars-d