On 11/16/15 8:11 PM, Meta wrote:
On Tuesday, 17 November 2015 at 00:30:39 UTC, Steven Schveighoffer wrote:
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 possible.
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.
-Steve
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.
http://stackoverflow.com/questions/31516713/escaping-from-inout-hell
I think it's quite clear that inout in its current form is a point of
huge confusion. I want to work to fix this perception (and fix the
broken corners of the implementation).
What I would ask is for those who at the moment dislike it keep an open
mind, and hold back on your pitchforks. I need to prepare a suitable
defense, and it's difficult to shake off the "confusing and complex"
albatross without having sufficient time to create something that is
easy to understand/explain for something that is conceptually simple,
but requires a complex proof.
What I am afraid of is that someone makes a decision that something is
bad, and by the time a good defense, or workable proposal is mounted,
the answer is "we already discussed that, it's bad. Let's move on."
At least with this, we have a feature that is part of the language, so
is unlikely to go away. But I'd hate to see a mob of PR requests that
remove inout from all of phobos/druntime before I can counter this.
I think inout is worth saving, it needs a few tweaks and a good explanation.
-Steve
