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.


T

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

On Thursday, September 22, 2016 00:14:52 H. S. Teoh via Digitalmars-d wrote:
> 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.

And in the case of operator overloads, FQN makes no sense at all, since it wouldn't be using the operator anymore.

- Jonathan M Davis

On Thursday, 22 September 2016 at 07:14:52 UTC, H. S. Teoh wrote:
>
> 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.
> ...
> T

I mean (in terms of your example) that in `main` before instantiate an `algorithm` we parse all symbols visible at this point from `main`, select all possible symbols which can be called with `UserType` (including templates, meh o_O), make the set union for the such table for the rest templates params, and give this symbol table the `algorithm`.

But yes this creates problem that in different module we can have different instantiation :(

Probably with other radical approach (see bellow *) for generic we can solve this, but this just destroy true templates (from which we benefits now) and provide something like Java-like solution :(

* radical approach for generic: each generic function creates a pseudo parameter for function pointers on the base of signature of function used in the body of generic. The caller of generic just fill this pseudo parameters with real function visible for caller at call-point.

On Thursday, 22 September 2016 at 08:53:26 UTC, HaraldZealot wrote:
>

OK, it seems to me it's time to investigate a community opinion.


So let's vote for the following sentence:

"It would be good to have an operator overloading even without support in generic function"

On Thursday, 22 September 2016 at 08:58:54 UTC, HaraldZealot wrote:
>
> So let's vote for the following sentence:
>
> "It would be good to have an operator overloading even without support in generic function"

Yes

On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote:
> There is no technical reason that would make the implementation of this feature difficult, if that is your question.
>
> Basically, the rationale is: external operators cannot be used in generic code that does not import the module defining the operators. C++ works around this using ADL. Walter (justifiably) does not like ADL, hence the limitation.
>
> (I don't agree with that line of reasoning: obviously this is not only an issue for operators, but for any UFCS function; operators are mere syntactic sugar.)


The greatest offender I've found is how in phobos, arrays do not behave as ranges without importing the module defining their range operations.

Which I think is obnoxious, and maybe there's a solution to make both cases less so, but I definitely don't think it's an argument for exclusion.

On 9/22/16 6:38 AM, pineapple wrote:
> The greatest offender I've found is how in phobos, arrays do not behave
> as ranges without importing the module defining their range operations.

Would make sense to move those few primitives to object.d. I've been thinking of that a long time ago but back then there was a vague stance that object.d shouldn't contain templates. Since then that has changed. -- Andrei

On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/22/16 6:38 AM, pineapple wrote:
> > The greatest offender I've found is how in phobos, arrays do not behave as ranges without importing the module defining their range operations.
>
> Would make sense to move those few primitives to object.d. I've been thinking of that a long time ago but back then there was a vague stance that object.d shouldn't contain templates. Since then that has changed. -- Andrei

The main problem with moving them there is auto-decoding. front and popFront for strings require std.utf in order to do their thing. So, if we move them to druntime, then that code would need to be duplicated (though similar code already has to exist in druntime for foreach loops), and we'd have a problem with invalid unicode in that it couldn't through std.utf.UTFException like it would now (though ideally, we'd stop throwing on invalid unicode and use the replacement character).

That being said, I agree that the range functions for arrays should go in object.d. It's just that the way we handle narrow strings as ranges makes it problematic.

- Jonathan M Davis

On 9/22/16 10:20 AM, Jonathan M Davis via Digitalmars-d wrote:
> The main problem with moving them there is auto-decoding. front and popFront
> for strings require std.utf in order to do their thing.

Yah, that's a little hurdle. -- Andrei

On Thu, Sep 22, 2016 at 07:20:49AM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, September 22, 2016 08:51:59 Andrei Alexandrescu via Digitalmars-d wrote:
> > On 9/22/16 6:38 AM, pineapple wrote:
> > > The greatest offender I've found is how in phobos, arrays do not behave as ranges without importing the module defining their range operations.
> >
> > Would make sense to move those few primitives to object.d. I've been thinking of that a long time ago but back then there was a vague stance that object.d shouldn't contain templates. Since then that has changed.  -- Andrei
> 
> The main problem with moving them there is auto-decoding.
[...]

Yet another nail in the coffin of autodecoding.  But I digress. ;-)


--T