Re: ADL

traits to existing types and also different implementations of the same traits. This gets really bloaty in C++, and that's why usually ADL is preferred, but D has the capability to reduce the overhead to a minimum. It doesn't quite make it possible to separate the implementation of types

Re: ADL

On 05.09.2016 15:35, Andrei Alexandrescu wrote: On 9/5/16 11:43 AM, Timon Gehr wrote: On 05.09.2016 06:05, Manu via Digitalmars-d wrote: An algorithm that calls a function on some T it receives just wants to look near the T; UFCS functions will be there. I agree with your post except for

Re: ADL

On Monday, 5 September 2016 at 13:35:02 UTC, Andrei Alexandrescu wrote: On 9/5/16 11:43 AM, Timon Gehr wrote: On 05.09.2016 06:05, Manu via Digitalmars-d wrote: An algorithm that calls a function on some T it receives just wants to look near the T; UFCS functions will be there. I agree

Re: ADL

On 9/5/2016 6:34 AM, Andrei Alexandrescu wrote: ADL would not apply here because it looks up only names in the same module as the type. It would work in C++ because any piece of code can insert more names into any namespace. Inserting names into a namespace violates about every principle

Re: ADL

On 9/5/16 4:41 PM, Jacob Carlborg wrote: On 2016-09-05 15:28, Andrei Alexandrescu wrote: Yah, make front a member please. It's in the same module so you're not breaking any encapsulation anyway. -- Andrei I just said: "I thought one of the reasons for UFCS was to be able to make a type

Re: ADL

On 2016-09-05 15:28, Andrei Alexandrescu wrote: Yah, make front a member please. It's in the same module so you're not breaking any encapsulation anyway. -- Andrei I just said: "I thought one of the reasons for UFCS was to be able to make a type support the range interface without modifying

Re: ADL

On 9/5/16 11:43 AM, Timon Gehr wrote: On 05.09.2016 06:05, Manu via Digitalmars-d wrote: An algorithm that calls a function on some T it receives just wants to look near the T; UFCS functions will be there. I agree with your post except for this. In general there could be four modules: one

Re: ADL

On 9/5/16 11:25 AM, Jacob Carlborg wrote: On 2016-09-05 11:06, Andrei Alexandrescu wrote: That is correct (and btw the example should use the member call syntax). But touching a type's module is modifying the type. -- Andrei Not sure what that has to do with anything. Example: module foo;

Re: ADL

On Saturday, 3 September 2016 at 11:24:01 UTC, Walter Bright wrote: On 9/3/2016 3:12 AM, Walter Bright wrote: If you are still determined to use it, you can use: __traits(compiles, ...) like you would SFINAE in C++ to select which of the modules from the argument types selects a function

Re: ADL

On Monday, 5 September 2016 at 01:00:26 UTC, Walter Bright wrote: What about using this template? Sure, it'll work assuming the module imports all its symbols publically, but it's still not as usable as it should be. I still need to invoke it for a number of things, including member

Re: ADL

On 05.09.2016 06:05, Manu via Digitalmars-d wrote: An algorithm that calls a function on some T it receives just wants to look near the T; UFCS functions will be there. I agree with your post except for this. In general there could be four modules: one defines the type, one defines the UFCS

Re: ADL

On Monday, 5 September 2016 at 08:17:15 UTC, Andrei Alexandrescu wrote: Are we in agreement about the baseline solution? Yes, but there are a bunch of cases in which the baseline solution is not applicable. Disclaimer: I don't know how C++ would handle the following situation. Let's say

[OT] local overloading (Was: Re: ADL)

is that you initially got it wrong. It /wants/ to be valid code. Maybe, but if I redesigned the language for every mistake I made, nothing would get done. ... The mistake is arguably in the language design here. (Lack of turtles.) My point with all this is ADL-workalike behavior can be reasonably done

Re: ADL

On 2016-09-05 11:06, Andrei Alexandrescu wrote: That is correct (and btw the example should use the member call syntax). But touching a type's module is modifying the type. -- Andrei Not sure what that has to do with anything. Example: module foo; struct Foo { int[] array = [1]; } int

Re: ADL

On 9/5/16 10:55 AM, Jacob Carlborg wrote: I thought one of the reasons for UFCS was to be able to make a type support the range interface without modifying the type. That is correct (and btw the example should use the member call syntax). But touching a type's module is modifying the type. --

Re: ADL

On 2016-09-05 10:17, Andrei Alexandrescu wrote: Let me make sure I understand it. The core structure is this: = module bob; struct S {} void f(S s); module myalgorithm; void test(T)(T t) { f(t); } = The core issue here is that f is not considered for lookup. It is a free function

Re: ADL

On 9/5/16 10:17 AM, Andrei Alexandrescu wrote: so the premise of http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 ... "does not apply". -- Andrei

Re: ADL

On 9/5/16 6:23 AM, Manu via Digitalmars-d wrote: But the point of my post is that I feel the problem is of very high importance. Let me make sure I understand it. The core structure is this: = module bob; struct S {} void f(S s); module myalgorithm; void test(T)(T t) { f(t); } =

Re: ADL

. And these modern D design patterns are the thing in D I'm most excited about, and keen to share with not-yet-D-users. Try the solutions I proposed - they aren't the ones you have been using. Give 'em a chance! As pointed out, C++ ADL is an awkward feature with ugly corner cases. If we add it to D, we'll

Re: ADL

the overloads could be done with the >>> existing language. >> >> That's not the point. What's perhaps more telling is that you initially >> got it >> wrong. It /wants/ to be valid code. > > > Maybe, but if I redesigned the language for every mistake I made, nothi

Re: ADL

gn > by comparison to the problems ADL introduces to C++, and D stands to > gain a lot more from the transaction, ie, UFCS will work in generic > functions the same as non-generic functions. D requires this much more > than C++ does, particularly when you take this as the direction of &

Re: ADL

UFCS (ie, pipeline style; *impossible in C++*) doesn't quite work properly, and it can be hard to understand why. UFCS needs to 'work', not 'sometimes work'. Let's forget I ever said C++ or ADL. I only raised it because I wondered why this wasn't a problem in C++, and then realised that ADL exist

Re: ADL

On 9/4/2016 1:48 PM, Ethan Watson wrote: Chipping in to say that I currently do something this with Binderoo templates... and it sucks. What about using this template? // Find module in which T was defined template ModuleOf(alias T) { import std.traits : moduleName; mixin("import " ~

Re: ADL

the language for every mistake I made, nothing would get done. My point with all this is ADL-workalike behavior can be reasonably done with existing D core features available *now* in all 3 compilers. It means we don't have to panic and rewrite the compiler right now - Manu can use these techniques

Re: ADL

On 04.09.2016 22:22, Walter Bright wrote: On 9/4/2016 5:30 AM, Andrei Alexandrescu wrote: Might be a sensible enhancement. Removing artificial limitations is good programming language design. Turtles! -- Andrei The design of executable function bodies is very much "declare before use", quite

Re: ADL

On Saturday, 3 September 2016 at 01:09:18 UTC, Walter Bright wrote: Fourth solution: module myalgorithm; void test(T)(T t) { import std.traits; mixin("import " ~ std.traits.moduleName!T ~ ";"); mixin("alias M = " ~ std.traits.moduleName!T ~ ";"); //

Re: ADL

On 9/4/2016 5:30 AM, Andrei Alexandrescu wrote: Might be a sensible enhancement. Removing artificial limitations is good programming language design. Turtles! -- Andrei The design of executable function bodies is very much "declare before use", quite unlike at the declaration levels which is

Re: ADL

On 9/4/2016 5:31 AM, Andrei Alexandrescu wrote: On 9/4/16 3:26 AM, Walter Bright wrote: On 9/3/2016 4:46 PM, Andrei Alexandrescu wrote: On 9/4/16 12:28 AM, Walter Bright wrote: On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote: On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu

Re: ADL

On 9/4/16 3:26 AM, Walter Bright wrote: On 9/3/2016 4:46 PM, Andrei Alexandrescu wrote: On 9/4/16 12:28 AM, Walter Bright wrote: On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote: On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module

Re: ADL

On 9/4/16 2:36 AM, Timon Gehr wrote: On 03.09.2016 13:24, Walter Bright wrote: Something like: void foo(T,U)(T t, U u) { alias func = ModuleOf!T.func; alias func = ModuleOf!U.func; func(t, u); } Does not work. Local overloads are not supported. Might be a sensible

Re: ADL

On 9/3/2016 10:57 PM, ZombineDev wrote: What do you think about making overloading and UFCS work with local symbols? I'd rather not. Let's make what we have work. There's an unending demand for new features in the core language. > There are workarounds, but nothing pretty. I don't regard

Re: ADL

On Sunday, 4 September 2016 at 01:34:47 UTC, Walter Bright wrote: On 9/3/2016 5:36 PM, Timon Gehr wrote: Does not work. Local overloads are not supported. Yeah, you're right, should have tested that: void abc(int); void def(uint); void foo() { alias func = abc; alias func =

Re: ADL

On 9/3/2016 5:36 PM, Timon Gehr wrote: Does not work. Local overloads are not supported. Yeah, you're right, should have tested that: void abc(int); void def(uint); void foo() { alias func = abc; alias func = def; // error func(1); } fails. Pushing it out a level

Re: ADL

On 9/3/2016 4:46 PM, Andrei Alexandrescu wrote: On 9/4/16 12:28 AM, Walter Bright wrote: On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote: On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module doesn't have an instance of func? static

Re: ADL

On 03.09.2016 13:24, Walter Bright wrote: Something like: void foo(T,U)(T t, U u) { alias func = ModuleOf!T.func; alias func = ModuleOf!U.func; func(t, u); } Does not work. Local overloads are not supported.

Re: ADL

On 9/4/16 12:28 AM, Walter Bright wrote: On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote: On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module doesn't have an instance of func? static if (traits(compiles, ModuleOf!T.func)) alias

Re: ADL

On 9/3/2016 3:35 AM, Walter Bright wrote: That isn't how it works in C++. It's done right up front in finding the candidates for overloading, not as a fallback. That statement is incorrect. It's used as a fallback in C++. I had forgotten.

Re: ADL

On 9/3/2016 1:43 PM, Andrei Alexandrescu wrote: On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module doesn't have an instance of func? static if (traits(compiles, ModuleOf!T.func)) alias func = ModuleOf!T.func; What's an

Re: ADL

also neglected. * The lack of said feature is regarded as an utter disaster and no workaround is even close to cutting the mustard. * A language change is a must; no library solution would ever be acceptable. For the most part this is a Pop a level up and figure what the needed accomplishm

Re: ADL

On 9/3/2016 9:24 AM, Andrei Alexandrescu wrote: On 9/3/16 5:57 PM, Manu via Digitalmars-d wrote: It's not a problem I've ever had. A problem you didn't know you have. It's a classic C++ conundrum combining theory and practice. One thing I've noticed in my years of programming and helping

Re: ADL

On 9/3/2016 6:22 AM, ZombineDev wrote: I agree that it's not a template issue. It's more of a modules vs namespaces issue. I think the lack of ADL is not a problem in C# because everyone can (and everyone does) extend an existing namespace, so most user's of LINQ algorithms just slap a `using

Re: ADL

the work, which means it needs to call other functions. There are no lambdas to be seen in this situation. This is purely a stylistic issue. I, on the other hand, think lambdas are a superior design, as ADL lookups never sat well with me because it can be quite difficult for the user to figure out

Re: ADL

On 9/3/16 10:43 PM, Walter Bright wrote: On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module doesn't have an instance of func? static if (traits(compiles, ModuleOf!T.func)) alias func = ModuleOf!T.func; What's an elegant way to encapsulate this as a stutter-free

Re: ADL

On 9/3/2016 8:34 AM, Manu via Digitalmars-d wrote: And if either module doesn't have an instance of func? static if (traits(compiles, ModuleOf!T.func)) alias func = ModuleOf!T.func;

Re: ADL

On 9/3/16 10:29 PM, Walter Bright wrote: On 9/3/2016 6:04 AM, Andrei Alexandrescu wrote: This only works with the respective modules do define `func`. We need something that conditionally plants the symbol depending on whether the module defines it or not. -- Andrei That's where

Re: ADL

On 9/3/2016 9:01 AM, Manu via Digitalmars-d wrote: Right, and it also has to not conflict with possible local definitions, or instances supplied by imports in the local namespace. Ie, the module where T came from is *an additional* place to look, not *the* place to look. I expect that local

Re: ADL

On 9/3/16 7:38 PM, Tobias Müller wrote: Andrei Alexandrescu wrote: On 9/3/16 7:08 PM, Tobias M wrote: On Saturday, 3 September 2016 at 16:33:07 UTC, Andrei Alexandrescu wrote: I see. This is a matter orthogonal to DbI - introspection should be able to figure

Re: ADL

On 9/3/2016 6:04 AM, Andrei Alexandrescu wrote: This only works with the respective modules do define `func`. We need something that conditionally plants the symbol depending on whether the module defines it or not. -- Andrei That's where __traits(compiles, ...) comes in. It can be

Re: ADL

ZombineDev <petar.p.ki...@gmail.com> wrote: > So what? C#'s generics are less flexible than C++ and D templates. > The point is that C#'s lookup does not consider only the > implemented interfaces, but also falls back to extensions > methods. If C# had ADL, > the com

Re: ADL

. If C# had ADL, the compiler would also look for extension methods in the namespace of the type (in non-generic methods, when the type is "known"), although the user of the type may not have imported the namespace. Sum is implemented in that stupid way, because unlike C++, in C# oper

Re: ADL

Andrei Alexandrescu wrote: > On 9/3/16 7:08 PM, Tobias M wrote: >> On Saturday, 3 September 2016 at 16:33:07 UTC, Andrei Alexandrescu wrote: >>> I see. This is a matter orthogonal to DbI - introspection should be >>> able to figure out whether a member can be found,

Re: ADL

On 9/3/16 7:08 PM, Tobias M wrote: On Saturday, 3 September 2016 at 16:33:07 UTC, Andrei Alexandrescu wrote: I see. This is a matter orthogonal to DbI - introspection should be able to figure out whether a member can be found, or a nonmember if the design asks for it. I wouldn't like "tricking"

Re: ADL

the module defines it or not. -- Andrei perhaps this: auto adl(string fn, T, Args...)(auto ref T x, auto ref Args args) Perhaps too surgical (although nice to have as an option). We need something that pulls the symbol for all purposes. -- Andrei

Re: ADL

Tobias M wrote: > On Saturday, 3 September 2016 at 16:32:16 UTC, ZombineDev wrote: >> Sum is implemented in that stupid way, because unlike C++, in >> C# operators need to be implemented as static methods, so you >> can't abstract them with an interface. If they were

Re: ADL

On Saturday, 3 September 2016 at 16:32:16 UTC, ZombineDev wrote: No you're wrong. There's no need for interfaces or for generic constraints. It's not static vs duck typing. It's just a method lookup issue. See for yourself: http://rextester.com/GFKNSK99121 Ok, Interfaces and other generic

Re: ADL

On Saturday, 3 September 2016 at 16:33:07 UTC, Andrei Alexandrescu wrote: I see. This is a matter orthogonal to DbI - introspection should be able to figure out whether a member can be found, or a nonmember if the design asks for it. I wouldn't like "tricking" DbI into thinking a member is

Re: ADL

it or not. -- Andrei perhaps this: auto adl(string fn, T, Args...)(auto ref T x, auto ref Args args){ import std.traits : moduleName, hasMember; import std.meta : Filter, NoDuplicates, staticMap; import std.array : join; static if(hasMember!(T, fn)){ mixin("return x.&

Re: ADL

On 9/3/16 4:09 PM, Tobias M wrote: On Saturday, 3 September 2016 at 12:25:11 UTC, Andrei Alexandrescu wrote: What problems are you referring to? -- Andrei The problems discussed here in the thread related to name lookup at template instantiation time. And also similar problems related to

Re: ADL

On Saturday, 3 September 2016 at 14:05:11 UTC, Tobias M wrote: On Saturday, 3 September 2016 at 12:40:26 UTC, ZombineDev wrote: No, LINQ doesn't work because of interfaces, but because of extension methods (C#'s variant of UFCS). The IEnumerable interface defines only a single method. All the

Re: ADL

On 9/3/16 5:57 PM, Manu via Digitalmars-d wrote: On 3 September 2016 at 22:42, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: On 9/3/16 1:51 AM, Manu via Digitalmars-d wrote: I've never thought about this problem in C++, or had any problems with ADL. How

Re: ADL

On 3 September 2016 at 23:04, Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 1:24 PM, Walter Bright wrote: >> >> On 9/3/2016 3:12 AM, Walter Bright wrote: >>> >>> If you are still determined to use it, you can use: >>> >>>__traits(compiles, ...) >>> >>>

Re: ADL

On 3 September 2016 at 22:42, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/3/16 1:51 AM, Manu via Digitalmars-d wrote: >> >> I've >> never thought about this problem in C++, or had any problems with ADL. > > > How do yo

Re: ADL

nd requires careful handling or you get hard to understand name-resolution issues. UFCS *is* modern D. Algorithms and ranges *is* modern D. Seriously, this is the style that modern D aspires to, and it doesn't 'just work'. There should be ear-piercing alarms and flashing red everywhere. This comes

Re: ADL

On 3 September 2016 at 21:24, Walter Bright via Digitalmars-d wrote: > On 9/3/2016 3:12 AM, Walter Bright wrote: >> >> If you are still determined to use it, you can use: >> >>__traits(compiles, ...) >> >> like you would SFINAE in C++ to select which of the

Re: ADL

On Saturday, 3 September 2016 at 12:25:11 UTC, Andrei Alexandrescu wrote: What problems are you referring to? -- Andrei The problems discussed here in the thread related to name lookup at template instantiation time. And also similar problems related to visibility (public/private) that were

Re: ADL

On Saturday, 3 September 2016 at 12:40:26 UTC, ZombineDev wrote: No, LINQ doesn't work because of interfaces, but because of extension methods (C#'s variant of UFCS). The IEnumerable interface defines only a single method. All the useful functionality is implemented as extension methods which

Re: ADL

On Saturday, 3 September 2016 at 10:11:05 UTC, Timon Gehr wrote: If ADL is done as a fallback, then it is only slower in those cases where it is either actually used, or __traits(compiles,...) is used to determine that some function overload does not exist. True. Still it does complicate

Re: ADL

the range functions as non-members. It's done for arrays via std.array. Nor have I seen ADL supported in any other language, despite many supporting generic algorithms. Which other such languages have templates like D or C++? I don't think it is a template issue. It's a name lookup issue

Re: ADL

On 2016-09-03 13:16, Walter Bright wrote: It's mostly about how templates specify what interface they require and how the requirements are satisfied by the caller. ADL is a workaround for the lack of a convenient enough such protocol in templates. Other approaches to generics solve

Re: ADL

On 9/3/16 1:24 PM, Walter Bright wrote: On 9/3/2016 3:12 AM, Walter Bright wrote: If you are still determined to use it, you can use: __traits(compiles, ...) like you would SFINAE in C++ to select which of the modules from the argument types selects a function that compiles. Eh, I

Re: ADL

this as an issue. The non-members would need to be in the same module even with ADL, so it's just a clerical matter. -- Andrei

Re: ADL

to use it as an example. https://github.com/dlang/phobos/pull/4762 Complexity ramps up further if there are N arguments to the algorithm. It needs to search each of the arguments modules. template adl(string fun){ /* TODO */ } adl!"foo"(S.init,T.init); Nice, yah, that kinds of stuff. -- Andrei

Re: ADL

On 9/3/16 3:09 AM, Walter Bright wrote: [snip] What would be really nice is to allow ADL easily and without fuss when needed. On Manu's example: module bob; struct S {} void f(S s); module joe; struct T {} void f(T t); module myalgorithm; void test(T)(T t) { mixin(adl!(T, "f"

Re: ADL

On 9/3/16 1:51 AM, Manu via Digitalmars-d wrote: I've never thought about this problem in C++, or had any problems with ADL. How do you swap two objects of a generic type that may or may not define its own swap? -- Andrei

Re: ADL

On Saturday, 3 September 2016 at 10:56:20 UTC, Tobias M wrote: On Saturday, 3 September 2016 at 10:33:22 UTC, Walter Bright wrote: I don't think it is a template issue. It's a name lookup issue. There's LINQ in C#, for example. I think it is. The problem is lookup of dependent symbols (see

Re: ADL

On 9/3/16 10:01 AM, Tobias Müller wrote: On Friday, 2 September 2016 at 23:51:35 UTC, Manu wrote: This pattern seems to bite me every direction I turn when trying to write range or algorithm style code. C++ has ADL, and ADL works. I've never thought about this problem in C++, or had any

Re: ADL

On 9/3/2016 3:12 AM, Walter Bright wrote: If you are still determined to use it, you can use: __traits(compiles, ...) like you would SFINAE in C++ to select which of the modules from the argument types selects a function that compiles. Eh, I realized it's simpler than that. Based on the

Re: ADL

On 9/3/2016 3:51 AM, Timon Gehr wrote: I don't think it is a template issue. It's a name lookup issue. It's both. ADL is mostly useless outside of generic code. It was initially justified as a solution for operator overloading, which has no necessary relationship to templates or generic

Re: ADL

On 9/3/2016 2:31 AM, Manu via Digitalmars-d wrote: I'm tired of these sorts of dismissals. You insist that I'm not a 'real' D programmer, or something to that effect. Not at all. No insult was intended. People often find better, more D idiomatic ways of writing code and tell me I need to

Re: ADL

On Saturday, 3 September 2016 at 10:33:22 UTC, Walter Bright wrote: I don't think it is a template issue. It's a name lookup issue. There's LINQ in C#, for example. I think it is. The problem is lookup of dependent symbols (see C++ two phase lookup). Without real templates, all lookup can be

Re: ADL

-members. It's done for arrays via std.array. ... This is not at all relevant when talking about 'this particular issue' that Manu brought up. std.range and std.algorithm import std.array. Nor have I seen ADL supported in any other language, despite many supporting generic algorithms

Re: ADL

working on. Sure it does, usually via a lambda passed to it. Recall that C++ ADL predates C++ lambdas by more than a decade, which may explain why C++ has come to rely on ADL.

Re: ADL

On 9/3/2016 3:11 AM, Timon Gehr wrote: If ADL is done as a fallback, then it is only slower in those cases where it is either actually used, That isn't how it works in C++. It's done right up front in finding the candidates for overloading, not as a fallback. Given Manu's other posts where

Re: ADL

because it's a perfect match for that workload, but same problem! Write an algorithm that does _work_, rather than does algorithm logic, and you can't miss this problem. You need to call associated functions to do work. I have had problems with not having C++ style ADL before, but in the end I'm

Re: ADL

std.array. Nor have I seen ADL supported in any other language, despite many supporting generic algorithms. Which other such languages have templates like D or C++? I don't think it is a template issue. It's a name lookup issue. There's LINQ in C#, for example.

Re: ADL

now require disambiguation. This surely represents a far higher probability of name collisions than the theoretical accidental collision that could come from ADL. The ADL style collision isn't accidental though, that's _the whole point_. // Find module in which T was defined template M

Re: ADL

On 03.09.2016 10:37, Walter Bright wrote: None of the algorithms used in std.algorithm or elsewhere in Phobos have this particular issue. Yes they do. It is not possible to implement the range functions as non-members. Nor have I seen ADL supported in any other language, despite many

Re: ADL

sed to qualify any function with the module in which one expects to find it. > Complexity ramps up further if there are N arguments to the algorithm. > It needs to search each of the arguments modules. Bluntly, if a library is designed around multi-argument ADL as a core requirement, red

Re: ADL

On 03.09.2016 03:12, Stefan Koch wrote: On Saturday, 3 September 2016 at 01:09:18 UTC, Walter Bright wrote: Essentially, ADL has awkward problems when getting beyond the simple cases. It isn't right for D. I could not agree more strongly! If this feature were supported, it would probably

Re: ADL

ub.com/dlang/phobos/pull/4762 Complexity ramps up further if there are N arguments to the algorithm. It needs to search each of the arguments modules. template adl(string fun){ /* TODO */ } adl!"foo"(S.init,T.init);

Re: ADL

On 3 September 2016 at 18:56, Walter Bright via Digitalmars-d wrote: > On 9/3/2016 1:37 AM, Walter Bright wrote: >> >> I thought #4 in particular was rather cool, I plan to use it as an >> example. > > > https://github.com/dlang/phobos/pull/4762 Complexity ramps up

Re: ADL

example. I also had this idea as workaround, but you can't seriously think this is okay? Importing an entire module at the point I want to call a function is crazy. I don't want to import _everything_ from T's module into my local namespace; that could easily lead to conflicting names in the local

Re: ADL

On 9/3/2016 1:37 AM, Walter Bright wrote: I thought #4 in particular was rather cool, I plan to use it as an example. https://github.com/dlang/phobos/pull/4762

Re: ADL

go "oh, i really wish i could do those things in C++!", because the problem is already solved :/ ADL has the problems I provided a link to. In any case, these difficulties are the consequence of trying to write C++ code in D. None of the algorithms used in std.algorithm or elsewhere

Re: ADL

On Friday, 2 September 2016 at 23:51:35 UTC, Manu wrote: This pattern seems to bite me every direction I turn when trying to write range or algorithm style code. C++ has ADL, and ADL works. I've never thought about this problem in C++, or had any problems with ADL. IMO the root

Re: ADL

it would make the compiler >> slower. > > > Note that C++ needs ADL in part because it cannot do options 2, 3 or 4. They're not solutions though, they're workarounds. They're all problematic, and highly unsavoury. Nobody is gonna go "oh, i really wish i could do those things in C++!", because the problem is already solved :/

Re: ADL

On 9/2/2016 6:12 PM, Stefan Koch wrote: If this feature were supported, it would probably break our module system. Even if we could shoehorn it into the language it would make the compiler slower. Note that C++ needs ADL in part because it cannot do options 2, 3 or 4.

Re: ADL

On Saturday, 3 September 2016 at 01:09:18 UTC, Walter Bright wrote: Essentially, ADL has awkward problems when getting beyond the simple cases. It isn't right for D. I could not agree more strongly! If this feature were supported, it would probably break our module system. Even if we could

Re: ADL

that. This pattern seems to bite me every direction I turn when trying to write range or algorithm style code. C++ has ADL, and ADL works. I've never thought about this problem in C++, First solution: module bob; struct S { void f(); } Second solution: module user_code; import

Re: ADL

On 3 September 2016 at 08:38, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/2/2016 5:15 AM, Manu via Digitalmars-d wrote: >> >> In C++, there is this ADL thing (argument dependent lookup). > > > Yeah, I know about Koening lookup. It w

  1   2   >