transporting qualifier from parameter to the return value

[Steven Schveighoffer]

On Tue, 15 Dec 2009 22:02:59 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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