any way to prevent overriding of .init ?

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Jun 13 13:06:23 PDT 2011


On 14.06.2011 0:03, Jonathan M Davis wrote:
> On 2011-06-13 12:50, Dmitry Olshansky wrote:
>> Right now there are lot of Phobos functionality that fully expects
>> A.init to return just that - a default initialized value of type A.
>>
>> Now consider:
>> struct A
>> {
>>       int i;
>>       void init(int K)
>>       {
>>           //blah
>>       }
>> }
>>
>> Then:
>> map!"a.i"([A(1), A(2), A(3)]);
>>
>> for me explodes with :
>> std\algorithm.d(382): Error: function test.A.init (int K) is not
>> callable using argument types ()
>> std\algorithm.d(382): Error: expected 1 function arguments, not 0
>> due to this line in std.algorithm:
>> alias typeof(_fun(.ElementType!R.init)) ElementType;
>>
>> Any way to circumvent this name lookup oddity and get to built-in property?
>> If there is, shouldn't we use it throughout Phobos?
>>
>> The issue is not a theoretical one - it severely limits usability of my
>> pull request (not posted because of this) that  makes dirEntries return
>> proper InputRange of DirEntry . Namely, DirEntry happen to define just
>> such a function (init).
> If init is causing a problem, get rid of it. It's scheduled for deprecation
> anyway, and it arguably never should have been called by anyone other than
> std.file in the first place.
>
Well, I that what I'm was thinking to do as 'right here, right now' 
solution.
Now taking into account that it wasn't documented before I'll just kill it.
Still, the general issue remains.

-- 
Dmitry Olshansky



More information about the Digitalmars-d mailing list