uniqueness

Steven Schveighoffer schveiguy at yahoo.com
Fri Dec 10 04:53:29 PST 2010


On Fri, 10 Dec 2010 07:40:49 -0500, Fawzi Mohamed <fawzi at gmx.ch> wrote:

>
> On 10-dic-10, at 11:53, Don wrote:
>
>> Fawzi Mohamed wrote:
>>
>>> If one could declare return or out types as unique (note that unique  
>>> is *not* part of the type, it is like the storage attributes), these  
>>> methods could be implicitly castable to const or immutable, allowing  
>>> nicer code.
>>> Constructors *might* return unique objects (an object is unique only  
>>> if all its references are to unique or immutable objects).
>>> In several cases uniqueness could be checked by the compiler. I think  
>>> that such a change would improve part of my code, removing the need  
>>> for several spurious casts, while at the same time making the code  
>>> safer.
>>
>> Any mutable object returned from a strongly pure function, is  
>> guaranteed to be unique.
>
> indeed good catch, I was saying that in some occasions the compiler can  
> verify uniqueness, that is indeed an important case.
>
> But I don't understand if you want to imply that uniqueness should not  
> be explicit, but just guaranteed to be detected and used in some  
> occasions, as in the case you gave.
>
> Because any object builder (as for example an array concatenate object)  
> cannot be pure, but can still return an unique object.

I'm not sure I understand your example, but why not?  Pure functions have  
gotten a lot better in the last release (with the possibility of  
weakly-pure functions).

I agree with Don, let's make strongly-pure functions implicitly castable  
and see how far we can get.  If we can do uniqueness without having to  
mess with the type system, then it will be much easier to deal with.

-Steve


More information about the Digitalmars-d mailing list