Re: Quality of errors in DMD

On 9/3/2016 7:35 PM, John Colvin wrote: In my experience getting a clue as to what is was the compiler didn't like is very useful. Often the only way I can find a workaround is by locating the assert in the compiler source and working out what it might possibly be to do with, then making

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 04:31:09 UTC, Jonathan M Davis wrote: He didn't say that it _couldn't_ be done. He said that it _shouldn't_ be done. - Jonathan M Davis Yes exactly.

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 04:35:15 UTC, rikki cattermole wrote: void writeln(T...)(T args) { if (__ctfe){ debug { __ctfeWriteln(args); } } else { // ... current implementation } } That will not work. The signature is void __ctfeWriteln(const string s)

Re: CompileTime performance measurement

On 04/09/2016 4:31 PM, Jonathan M Davis via Digitalmars-d wrote: On Sunday, September 04, 2016 16:24:34 rikki cattermole via Digitalmars-d wrote: On 04/09/2016 4:14 PM, Stefan Koch wrote: On Sunday, 4 September 2016 at 04:10:29 UTC, rikki cattermole wrote: On 04/09/2016 2:08 PM, Stefan Koch

Re: CompileTime performance measurement

On Sunday, September 04, 2016 16:24:34 rikki cattermole via Digitalmars-d wrote: > On 04/09/2016 4:14 PM, Stefan Koch wrote: > > On Sunday, 4 September 2016 at 04:10:29 UTC, rikki cattermole wrote: > >> On 04/09/2016 2:08 PM, Stefan Koch wrote: > >>> On Sunday, 4 September 2016 at 02:06:55 UTC,

Re: CompileTime performance measurement

On 04/09/2016 4:14 PM, Stefan Koch wrote: On Sunday, 4 September 2016 at 04:10:29 UTC, rikki cattermole wrote: On 04/09/2016 2:08 PM, Stefan Koch wrote: On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote: This works already. Anything placed in a debug {} block will be considered

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 04:10:29 UTC, rikki cattermole wrote: On 04/09/2016 2:08 PM, Stefan Koch wrote: On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote: This works already. Anything placed in a debug {} block will be considered pure regardless. Opps your comment was

Re: CompileTime performance measurement

On 04/09/2016 2:08 PM, Stefan Koch wrote: On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote: This works already. Anything placed in a debug {} block will be considered pure regardless. Opps your comment was about the debate. I would say that __ctfeWriteln and __ctfeTicksMs should

Re: colour lib

On 04/09/2016 5:44 AM, Marco Leise wrote: Am Sat, 3 Sep 2016 16:01:26 +1200 schrieb rikki cattermole : Something[0] along this line perhaps? Overview of the choices and scope along with reasoning. [0]

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 19:31:12 UTC, Jacob Carlborg wrote: That can usually be solved using .tupleof[i], but I agree. Well, .tupleof gives you a typed representation of the memory layout, to me it's something different than qualified access of fields, just a safer mean to access

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 18:56:33 UTC, Dicebot wrote: Obviously serialization libraries come to mind, especially important for binary serialization because private members still affect the layout of the struct. Let me repeat that another time, private members have never been

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 17:23:53 UTC, Basile B. wrote: On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote: On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I don't agree with the current solution: Well let's come up with a better solution then. Let's

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 03:21:05 UTC, Stefan Koch wrote: While I do understand, that there could be a potential performance when private members could be changed around because they are not visible form outside. I fail to see how we would take advantage of that without breaking our

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 17:57:08 UTC, Jonathan M Davis wrote: I do get the feeling that too much of what we do with features like this is ad-hoc without really designing things up front, and then we keep having to tweak stuff as we go along in ways that aren't always particularly

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Sunday, 4 September 2016 at 03:14:18 UTC, Martin Nowak wrote: It didn't slip, but I wish Walter had at least stated his opinion on the PR before merging. My thinking is that the plebes should be able to access things via the object.member syntax by obeying the usual visibility rules.

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: On 9/3/16 7:57 PM, Jonathan M Davis via Digitalmars-d wrote: Previously __traits(allMembers, T) listed _all_ members, whereas now it wil only list the ones that are accessible. The same for __traits(derivedMembers, T).

Re: Quality of errors in DMD

On Saturday, 3 September 2016 at 22:48:27 UTC, Walter Bright wrote: On 9/3/2016 6:20 AM, Adam D. Ruppe wrote: On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright wrote: Except that asserts are checking for compiler bugs, not diagnostics on user code. Except that in the real world,

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 02:06:55 UTC, Stefan Koch wrote: This works already. Anything placed in a debug {} block will be considered pure regardless. Opps your comment was about the debate. I would say that __ctfeWriteln and __ctfeTicksMs should not work outside of debug.

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 02:03:49 UTC, sarn wrote: On Sunday, 4 September 2016 at 01:53:21 UTC, Stefan Koch wrote: Pragma msg can only print compiletime constants. While __ctfeWriteln can print state while doing CTFE. Thanks, that makes a lot of sense. Just to check, it prints to

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 01:53:21 UTC, Stefan Koch wrote: Pragma msg can only print compiletime constants. While __ctfeWriteln can print state while doing CTFE. Thanks, that makes a lot of sense. Just to check, it prints to standard error, right? Also, the issue of non-deterministic

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 01:44:40 UTC, sarn wrote: On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: I recently implemented __ctfeWriteln. Sounds like pragma msg. How does it compare? https://dlang.org/spec/pragma.html#msg Pragma msg can only print compiletime

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: I recently implemented __ctfeWriteln. Sounds like pragma msg. How does it compare? https://dlang.org/spec/pragma.html#msg

Re: Quality of errors in DMD

On 9/3/2016 5:09 PM, Stefan Koch wrote: Perhaps the best error message would be "Please post this as a bug to bugzilla." That's fine with me, and Dicebot made a PR to do it.

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: DIP1001: DoExpression

On 03.09.2016 17:28, Andrei Alexandrescu wrote: What's wrong with: auto seq(T...)(auto ref T vals) { return vals[$ - 1]; } - The name (I'd expect that function to return vals). - Does not work if one or more arguments is of type 'void'. (Arguably that's just a language misdesign.)

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 00:08:14 UTC, David Nadlinger wrote: Please don't. This makes CTFE indeterministic. Please elaborate on why this would have a negative impact ? if someone chooses to use a symbol called __ctfeTicksMs they shoud know what they are doing. To write performance

Re: Quality of errors in DMD

On Saturday, 3 September 2016 at 22:53:25 UTC, Walter Bright wrote: On 9/3/2016 3:05 PM, Ethan Watson wrote: In the cases I've been bringing up here, it's all been user code that's been the problem *anyway*. Regardless of if the compiler author was expecting code to get to that point or not,

Re: CompileTime performance measurement

On Sunday, 4 September 2016 at 00:04:16 UTC, Stefan Koch wrote: Based on that experience I have now implemented another pseudo function called __ctfeTicksMs. […] Please tell me what you think. Please don't. This makes CTFE indeterministic. To write performance tests, just measure compilation

CompileTime performance measurement

Hi Guys. I recently implemented __ctfeWriteln. Based on that experience I have now implemented another pseudo function called __ctfeTicksMs. That evaluates to a uint representing the number of milliseconds elapsed between the start of dmd and the time of semantic evaluation of this

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: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 11:54 PM, Jacob Carlborg wrote: On 2016-09-03 22:40, Andrei Alexandrescu wrote: That... doesn't sound good. I wonder how such important changes slip by Walter and myself unnoticed. Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078 Thanks. -- Andrei

Re: Quality of errors in DMD

On 9/3/2016 3:05 PM, Ethan Watson wrote: In the cases I've been bringing up here, it's all been user code that's been the problem *anyway*. Regardless of if the compiler author was expecting code to get to that point or not, erroring out with zero information is a bad user experience. Nobody

Re: Quality of errors in DMD

On 9/3/2016 6:20 AM, Adam D. Ruppe wrote: On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright wrote: Except that asserts are checking for compiler bugs, not diagnostics on user code. Except that in the real world, it is an irrelevant distinction because you have stuff to do and

Re: Quality of errors in DMD

On 9/3/2016 6:14 AM, Jacob Carlborg wrote: What kind of issue due you see with trying to print some form of information when an assertion fails? Because it's useless to anyone but the compiler devs, and it adds cruft to the compiler. And even worse than useless, it confuses the user into

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: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 21:54:24 UTC, Jacob Carlborg wrote: Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078 I'm certainly not going to upgrade to the next DMD if this change is retained. allMembers not returning all members makes introspection

Re: Quality of errors in DMD

On Saturday, 3 September 2016 at 13:20:37 UTC, Adam D. Ruppe wrote: Except that in the real world, it is an irrelevant distinction because you have stuff to do and can't afford to wait on the compiler team to actually fix the bug. If nothing else, you'd like to know where it is so you can

dependency analysis for makefile construction

Are there any FOSS tools for doing dependency analysis of (e.g.) all the d files in a directory, to let you know when a .o file needs to be regenerated? This presumably would depend mostly on the import statements (including import of any file to be used in string construction, as in 'auto

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-03 22:40, Andrei Alexandrescu wrote: That... doesn't sound good. I wonder how such important changes slip by Walter and myself unnoticed. Here's the PR that introduced the change: https://github.com/dlang/dmd/pull/6078 -- /Jacob Carlborg

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:54:19 UTC, Andrei Alexandrescu wrote: On 9/3/16 10:50 PM, Basile B. wrote: On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change

[Issue 15442] Eponymous template restrictions should be documented

https://issues.dlang.org/show_bug.cgi?id=15442 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 15442] Eponymous template restrictions should be documented

https://issues.dlang.org/show_bug.cgi?id=15442 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/190da42b6d6fe0abc205fda66a1d0e4086c5cf5c fix issue 15442 - Eponymous template restrictions

Re: ADL

On 9/3/16 11:31 AM, Manu via Digitalmars-d wrote: > In any case, these difficulties are the consequence of trying to write C++ > code in D. You've told me this before, and I find it kind of offensive every time you do, since I've been programming D for like 7 years now, and I definitely don't

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

On 9/3/2016 8:51 AM, Manu via Digitalmars-d wrote: This is exactly the difference between std.algorithm, and what I was trying to express as an algorithm that 'does work'. It's not the business of the API for the user to supply the work to do (ie, via lambda); the function is meant to do the

Re: Fallback 'catch-all' template functions

Am Sat, 3 Sep 2016 02:56:16 -0700 schrieb Walter Bright : > On 9/3/2016 2:43 AM, Manu via Digitalmars-d wrote: > > This is interesting. Can you explain how that works? > > > Specializations are preferred over non-specializations, and T:T is the > identity >

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 10:50 PM, Basile B. wrote: On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change then what will happen again is that the results of allMembers won't be

Re: Fallback 'catch-all' template functions

Am Sat, 3 Sep 2016 14:24:13 +0200 schrieb Andrei Alexandrescu : > On 9/3/16 7:29 AM, Manu via Digitalmars-d wrote: > > On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d > > wrote: > >> On 9/3/16 2:41 AM, Manu via

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 20:40:57 UTC, Andrei Alexandrescu wrote: Martin, any chance we can undo this change to the language? The problem is deeper. If he undoes the change then what will happen again is that the results of allMembers won't be usable by the other traits, e.g

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: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 7:57 PM, Jonathan M Davis via Digitalmars-d wrote: Previously __traits(allMembers, T) listed _all_ members, whereas now it wil only list the ones that are accessible. The same for __traits(derivedMembers, T). So, they'll still give you the private members if you use them inside the

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

Poodinis (DI framework) 7.0.0 released

Poodinis is a dependency injection framework for the D programming language. It is heavily inspired by the Spring Framework. New in this release is constructor injection. Whenever the dependency container resolves a class it creates an instance of that class. During creation it attempts to

[Issue 16457] std.regex postprocesses ctRegex every time at runtime

https://issues.dlang.org/show_bug.cgi?id=16457 --- Comment #2 from greenify --- thanks a lot for looking at this so quickly :) > The problem is enum re = ... line. Enum means ctRegex!`((c)(s)?)?ti` is > copy-pasted at the place of usage, basically reconstructing regex on

[Issue 16457] std.regex postprocesses ctRegex every time at runtime

https://issues.dlang.org/show_bug.cgi?id=16457 Dmitry Olshansky changed: What|Removed |Added CC|

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-03 20:56, Dicebot wrote: Obviously serialization libraries come to mind, especially important for binary serialization because private members still affect the layout of the struct. That can usually be solved using .tupleof[i], but I agree. -- /Jacob Carlborg

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 2016-09-03 17:50, Martin Nowak wrote: It will, e.g. having getMember bypass protection means vibe.d would now serialize private members https://github.com/rejectedsoftware/vibe.d/blob/c1180791de61d0f8c9bfb584c2551a5b64627e32/source/vibe/internal/meta/traits.d#L146. Until now getMember was

Re: Beta D 2.071.2-b3

On 2016-09-03 18:02, Martin Nowak wrote: Why not just use `__traits(getAttributes, var.tupleof[0])`? I've already updated my code to use the above. When I first implemented it, it was not possible to use a "tupleof expression" as argument to __traits(getAttributes). -- /Jacob Carlborg

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 09/03/2016 07:52 PM, Martin Nowak wrote: > On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: >> I don't agree with the current solution: > > Well let's come up with a better solution then. > Let's start by finding some proper use-cases that require introspection > on private

[Issue 15625] Internal error: backend/elfobj.c 1014

https://issues.dlang.org/show_bug.cgi?id=15625 --- Comment #5 from Mark Isaacson --- I'll work on getting one at the next hackathon. --

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, September 03, 2016 19:30:54 Andrei Alexandrescu via Digitalmars-d wrote: > On 9/3/16 6:39 PM, Andrej Mitrovic via Digitalmars-d wrote: > > On 9/3/16, Martin Nowak via Digitalmars-d wrote: > >> On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe

Re: ADL

ZombineDev 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 compiler would also look for

Re: colour lib

Am Sat, 3 Sep 2016 16:01:26 +1200 schrieb rikki cattermole : > On 03/09/2016 12:17 PM, Manu via Digitalmars-d wrote: > ...snip... > > > I think the presence of all this colour space information as type > > arguments should nudge users in the right direction. They'll be

Re: ADL

On Saturday, 3 September 2016 at 17:05:35 UTC, Tobias M wrote: 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:

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

On 9/3/16 7:00 PM, vit wrote: On Saturday, 3 September 2016 at 13:04:30 UTC, Andrei Alexandrescu 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, ...) like you would SFINAE in

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16 6:39 PM, Andrej Mitrovic via Digitalmars-d wrote: On 9/3/16, Martin Nowak via Digitalmars-d wrote: On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: Ugh, it really should just give everything and have getMember bypass it. That won't even

Re: DIP1001: DoExpression

On 9/3/16 6:39 PM, Cauterite wrote: On Saturday, 3 September 2016 at 16:28:15 UTC, Andrei Alexandrescu wrote: This is a terrible argument. It has "why not" all over it. -- Andrei Sorry, it's my first time proposing a language feature. My DConf 2016 talk has a few considerations on what

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: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote: On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I don't agree with the current solution: Well let's come up with a better solution then. Let's start by finding some proper use-cases that require introspection

Re: phobos unit tests

On Saturday, September 03, 2016 16:56:08 ZombineDev via Digitalmars-d wrote: > You can just enable the unittests for a single instance that you > know for sure that it will be used. For example: > 1) > https://github.com/dlang/phobos/blob/v2.071.2-b3/std/experimental/ndslice/sl > ice.d#L808 > > 2)

Re: Using OpenGL

On Saturday, 3 September 2016 at 16:07:52 UTC, Mike Parker wrote: On Saturday, 3 September 2016 at 16:01:34 UTC, Mike Parker wrote: The following compiles, runs, and shows the triangle. It's the code you posted above with the corrected call to glBufferData along with more D style (as I would

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

On Saturday, 3 September 2016 at 13:04:30 UTC, Andrei Alexandrescu 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, ...) like you would SFINAE in C++ to select which of the

Re: phobos unit tests

On Saturday, 3 September 2016 at 15:58:51 UTC, Jonathan M Davis wrote: On Saturday, September 03, 2016 07:48:14 H. S. Teoh via Digitalmars-d wrote: > In any case, for now, I never put non-generic unit tests in > templates, and I reject PRs that have them. Sure, having to > copy-paste your

Re: phobos unit tests

On Saturday, 3 September 2016 at 15:54:31 UTC, Jonathan M Davis wrote: On Saturday, September 03, 2016 15:06:33 Andrei Alexandrescu via Digitalmars-d wrote: On 9/3/16 5:36 AM, Manu via Digitalmars-d wrote: > This document: https://wiki.dlang.org/Contributing_to_Phobos > > States: "Avoid

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote: I don't agree with the current solution: Well let's come up with a better solution then. Let's start by finding some proper use-cases that require introspection on private members w/o having access to them.

Re: DIP1001: DoExpression

On Saturday, 3 September 2016 at 16:03:39 UTC, Jonathan M Davis wrote: So, instead of having the return statement which everyone knows to look for and is easy to grep for, you want to add a way to return _without_ a return statement? I think you've misunderstood. Even with DoExpressions, the

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On 9/3/16, Martin Nowak via Digitalmars-d wrote: > On Wednesday, 31 August 2016 at 13:12:30 UTC, Adam D. Ruppe wrote: >> Ugh, it really should just give everything and have getMember >> bypass it. That won't even break any code! > > It will, e.g. having getMember

Re: DIP1001: DoExpression

On Saturday, 3 September 2016 at 16:28:15 UTC, Andrei Alexandrescu wrote: This is a terrible argument. It has "why not" all over it. -- Andrei Sorry, it's my first time proposing a language feature.

Re: DIP1001: DoExpression

On Saturday, 3 September 2016 at 16:10:16 UTC, Jonathan M Davis wrote: .. and from what I've seen, it seems to be the case that just about only the only folks who read it correctly are the ones who use it frequently .. You know what else is easy to misread? { x; y; return z; }();

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

On Wednesday, 31 August 2016 at 21:12:54 UTC, Ali Çehreli wrote: On 08/30/2016 03:24 PM, Ali Çehreli wrote: > v2.071.2-b3 is bringing a change for this bug: > > https://issues.dlang.org/show_bug.cgi?id=15907 > > I don't agree with the current solution: > >

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: DIP1001: DoExpression

On 9/3/16 6:19 PM, Cauterite wrote: On Saturday, 3 September 2016 at 15:28:36 UTC, Andrei Alexandrescu wrote: What's wrong with: auto seq(T...)(auto ref T vals) { return vals[$ - 1]; } Well there's nothing *wrong* with that, but I really think that 'do' is the perfect word for this purpose,

Re: Fallback 'catch-all' template functions

On 9/3/16 6:10 PM, Manu via Digitalmars-d wrote: We do this sort of things a lot. Consider std.conv.to? std.conv.to is not a frequently done thing. -- Andrei

Re: DIP1001: DoExpression

On 9/3/16 6:10 PM, Jonathan M Davis via Digitalmars-d wrote: I think that we're much better off just killing it off. We're better off with what we have right now: you can use comma, just don't take the last value. Absent a smoking gun (and one very smokey and stinky at that), I don't see

Re: Beta D 2.071.2-b3

On Saturday, 3 September 2016 at 14:40:37 UTC, Martin Nowak wrote: Yes, it does help. As private prevents usage outside of a module it allows to do some optimizations that required whole program analysis otherwise, e.g. variables and functions can get internal linkage, thus reducing

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 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 you

Re: DIP1001: DoExpression

On Saturday, 3 September 2016 at 15:28:36 UTC, Andrei Alexandrescu wrote: What's wrong with: auto seq(T...)(auto ref T vals) { return vals[$ - 1]; } Well there's nothing *wrong* with that, but I really think that 'do' is the perfect word for this purpose, and the fact that it's already a

  1   2   >