transporting qualifier from parameter to the return value

Steven Schveighoffer schveiguy at yahoo.com
Tue Dec 15 20:02:36 PST 2009


On Tue, 15 Dec 2009 22:43:55 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-12-15 22:02:59 -0500, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> said:
>
>> Time has come to make a decision on implementing Steven Schveighoffer's  
>> proposal:
>>  http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP2
>>  It's been in the back of my mind for a while now, I don't find a fault  
>> with it, it solves a very unpleasant problem that would seriously mar  
>> qualifiers, and although it doesn't solve 100% of the potential cases,  
>> it does solve a good fraction of them. I am confident that we can  
>> require body duplication for the remaining stragglers with a straight  
>> face.
>>  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.
>>  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.
>>  Any thoughts would be appreciated.
>
> inout? I guess you mean you decided to rename vconst by inout. I can't  
> seem to find a better name, so I guess it's good enough.
>
> But I see a flaw in accepting shared. And vconst might be a better name  
> after all. Here's the explanation.
>
> So what code inout would generate now? Generate one copy of the function  
> for each possible combination? It can't really do otherwise because the  
> const and non-const versions of other functions it calls might be  
> separate functions too, with separate addresses:
>
> 	class Test {
> 		void doThat() immutable {}
> 		void doThat() const {}
> 		void doThat() {}
> 		void doThat() shared immutable {}
> 		void doThat() shared const {}
> 		void doThat() shared {}
>
> 		void doSomething() inout // or vconst
> 		{
> 			doThat(); // which doThat does it call?
> 		}
> 	}

First, the proposal as I see it is to compile *one* copy of doSomething  
(see points 5 and 6 in the DIP description).  Second, inout (or vconst)  
implicitly casts to const, so it can call any functions that require const  
*or* that require inout.  Third, and this is kind of a nitpick, inout  
functions should *require* inout in the return type, otherwise, there's no  
point, the qualifier could just be const :)  So your example is  
technically invalid.

So to answer your question, doSomething can only call:

void doThat() const {}

and I don't think shared can be involved because there is no common type  
you can implicitly cast const, immutable, mutable and shared to.

One further nitpick, shared immutable is useless :)

-Steve



More information about the Digitalmars-d mailing list