transporting qualifier from parameter to the return value

[Denis Koroskin]

On Wed, 16 Dec 2009 07:20:11 +0300, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Tue, 15 Dec 2009 23:04:38 -0500, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Michel Fortin wrote:
>>> On 2009-12-15 22:41:19 -0500, "Steven Schveighoffer"  
>>> <schveiguy at yahoo.com> said:
>>>
>>>> 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.
>>>  Seconded. In fact, we could just remove inout from the keyword list  
>>> if we care about not augmenting the number of keywords.
>>
>> Regardless of legacy, I personally find "inout" more suggestive - the  
>> qualifier goes from input to output. vconst doesn't quite tell me  
>> anything. I don't even know what "v" stands for.
>
> "virtual" const :)
>
> My original proposal called the technique "Scoped" const, which I think  
> is pretty accurate, since the data is const only for the scope of the  
> function.  perhaps sconst?
>
> or aconst for "any" const?
>
> In any case inout is fine by me if that's what gits 'er done.  The only  
> problem I see with inout is that it has legacy issues.
>
> -Steve

I suggested sameconst/shareconst. It is longer but I believe it's more  
descriptive, as it describes that two (or more) types share the same  
"constness modifier".

sameconst(T)[] find(sameconst(T)[] haystack, T needle) { ... } // my  
solution to your inout(T)[] problem

It could be shortened to same(T) but people didn't like it either.

I think it should be bikeshed(T)! :)