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