On Thu, Sep 22, 2016 at 06:09:39AM +0000, HaraldZealot via Digitalmars-d wrote:
> On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot wrote:
> > And problem  with generic code solve independently for all UFCS
> > functions including operators.
> Unfortunately I don't know compiler and all related stuff internally
> (time to change this ;) ), but it seems to me there is a way to solve
> problem with UFCS and generic code without breakage of module
> encapsulation. If understand correctly when we instantiate template
> with struct/class we pass to template some kind of "static signature
> of type" (if I may it call so).  With the static signature of type I
> mean all member function of class or struct. If we instead of this
> before instantiate any type (including POD) create "dynamic signature
> of type" which include all visible at the moment of call function and
> templates for this type.

It's not so simple.  The UFCS operator overload could be declared in a
different module from the type itself.  Then there is no guarantee that
it will be found.  Multiple calls to the same template function with the
same argument types may result in different semantics, depending on what
was imported.

Or there could be more than one module that declares the operator,
possibly with conflicting semantics.  Normally this isn't a problem (D's
module system will trigger an overload conflict and require explicit FQN
to unambiguously select the right overload), but FQN's are not an option
when the call is made from generic code.


Ignorance is bliss... until you suffer the consequences!

Reply via email to