--- Comment #7 from Steven Schveighoffer <schvei...@yahoo.com> 2012-04-04
11:33:27 PDT ---
(In reply to comment #6)
> >look it up from two scopes -- the template definition scope (i.e. bar.d) and
> >the scope where S is defined (i.e. foo.d).
> I thought this too, although the need to extend unknown types
> at the template scope will be limited.
Templates already introduce a large level of binary incompatibility. This
proposal of LOCAL templates will make it even worse, to the point where
possibly no binary compatibility will be feasible as long as UFCS is involved.
consider that I could import some module that declares a UFCS method foo. Then
I call a template function that uses this method. In another module, I also
import the same module for foo, call the same template, which generates the
exact same code for the exact same function, but now has TWO identical
instantiations based on the instantiating module's name.
> There is one important use-case where this fails though.
> Extending library types so that they fit a library template, e.g.
> to use std.stream.Stream with std.algorithm.find I need to modify
You can do this probably with alias this.
But one thing I am concerned about is how a type can arbitrarily take on
different API depending on the modules you import. It makes things confusing
and unexpected. I'd rather have the type define what API it takes, along with
the template, who is obviously free to extend any types it wants.
My main concern with UFCS is about the use case where we have an existing
method m, which I want to move outside the class or struct (for whatever
reason). Both Walter's and my proposals should cover this case, but mine I
think does it without adding unnecessary bloat or complexity to the name
My proposal is also a subset of Walter's. That is, we could *still* go the
LOCAL template route later without breaking existing code.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------