any way to prevent overriding of .init ?

[Jonathan M Davis]

On 2011-06-13 13:06, Dmitry Olshansky wrote:
> 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.

True. And I would argue that it should probably be illegal to declare a 
function with the name init which is not a free function. Maybe that would be 
unacceptable for some reason, but it seems to me that it would solve the 
problem quite cleanly.

- Jonathan M Davis