On Tue, 15 Dec 2009 22:02:59 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Time has come to make a decision on implementing Steven Schveighoffer's
proposal:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2
I'll note that this is not my proposal, my original proposal is in the
referenced bug 1961. I did modify the DIP a bit.
My main concern is allowing shared to participate to the inout
transportation. I am tempted to allow it, but shared is constrained much
more severely than the other two.
It doesn't work, because shared doesn't implicitly cast to const. During
the function body, the parameters tagged with inout are treated as if they
were tagged as const. It works for immutable, const and mutable because
all those implicitly cast to const. Shared isn't the same, because it
requires synchronization even when viewed using const. In addition, if
you store a pointer to something that is const during such a function, it
is valid after the function exits, a pointer to something shared has to go
back to being shared after the function exits, it can't remain as const.
I think, however, this may not be much of an issue. I don't think there
are as many use cases for data types that are meant to be both shared and
unshared than there are data types meant to be *only* shared or unshared.
To avoid problems with the existing uses of inout (which is an old
synonym for ref), the language requires that you redundantly use inout
in the return type as well. We could eliminate that in D3.
2 points here:
1. inout is not necessarily used on the *entire* return type. For
instance, I'd consider inout(T)[] to be the most useful return type for
array processing functions, not inout T[]. It would be difficult to
eliminate this requirement and still allow such specificity. However, we
already have a way to "eliminate" it -- auto.
2. the choice of inout is not my first choice, I'd prefer a new keyword.
The inout compromise was meant to subvert the "we already have too many
keywords" argument (it was Janice's idea). If there are no objections, I
prefer what the DIP proposed, vconst. All I'm saying is, reusing inout is
*not* a very important part of the proposal.
-Steve
