On 04/15/12 03:01, Piotr Szturmaj wrote:
> Artur Skawina wrote:
>> @property is for functions masquerading as data, i'm not sure extending it
>> to pointers and delegates would be a good idea. What you are asking for is
>> basically syntax sugar for:
>>
>> struct CommonInputRange(E)
>> {
>> bool delegate() _empty;
>> @property auto empty() { return _empty(); };
>> @property auto empty(typeof(_empty) dg) { _empty = dg; };
>> E delegate() _front;
>> @property auto front() { return _front(); };
>> @property auto front(typeof(_front) dg) { _front = dg; };
>> void delegate() popFront;
>> }
>>
>
> Yes, I was thinking about this, but it adds unnecessary overhead. I want to
> call delegates directly.
The compiler has to implement it internally exactly like that anyway. D's design
relies on such code being efficient - there is no preprocessor, no inline
attribute and no macros. The trivial functions have to be inlined, if that
doesn't happen it's a compiler bug. Once inlined, there's no overhead.
> I think the whole idea is harmless because semantically, from the user
> perspective, delegates and function pointers works just like normal
> functions. So, why not?
I can see it being confusing and don't see much benefit - that's all. The
current
syntax is just a little more verbose, and mixins could be used if this scheme
had
to be used on a larger scale.
artur
