ref returns and properties

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Jan 26 08:06:05 PST 2009


Daniel Keep wrote:
> 
> Sean Kelly wrote:
>> Daniel Keep wrote:
>>> Andrei Alexandrescu wrote:
>>>> Denis Koroskin wrote:
>>>>> [snip]
>>>>>
>>>>> get/set/free?
>>>> With these you can't move a resource inside the property.
>>>>
>>>> Andrei
>>> Python has an overload for removing properties.  In all my years of
>>> using Python, I've *NEVER* once had a use for it, or even worked out why
>>> I'd want to use it.
>>>
>>> I'm not saying we shouldn't be able to do this, I just can't see the
>>> need for move/remove for properties; where would this be useful?
>> Does Python have complex value types?
>>
>>
>> Sean
> 
> You mean these?
> 
>>>> (1+2j) * (2+3j)
> (-4+7j)
> 
> Don't ask me why they used 'j' instead of 'i'.  :P
> 
> If you mean aggregate types that have value semantics, then no.

He meant the latter (emphasis on the other syllable, I always forget 
which is which). This brings back the notion of precision and 
efficiency. C++ tries to define operations such that some never throw, 
as those can be used in code with transactional semantics. It also tries 
to manage resources deterministically, which means there's strict 
control over values being created and destroyed. It's hard to combine 
these two within a harmonious system.

Anyhow, here's a simple D example. Consider we define a BigInt type as a 
value-type struct: when you copy a BigInt to another, the latter becomes 
an independent copy:

BigInt a = 100;
BigInt b = a;
++b;
assert(a == 100);

BigInt's copy constructor would allocate memory dynamically, which means 
it may throw and also that it is inefficient to copy BigInt objects 
unwittingly.

So far, so good. Now say we define some range that iterates over 
BigInts. If that range chooses to implement head() as a property, then a 
copy is created whenever you ask for head. The small problem is that 
that's inefficient. The larger problem is that there is no way to 
correctly e.g. sort such a range. Sorting hinges on swap, and with 
properties you can't ever swap without risking to throw. Sort would end 
up throwing, and not only throwing, but losing state irretrievably while 
at it. Well that's not a foundation we want to build D on, do we?


Andrei



More information about the Digitalmars-d mailing list