On Sunday, 26 April 2020 at 16:07:30 UTC, Steven Schveighoffer wrote:
> On 4/25/20 2:52 PM, Paul Backus wrote:
>> On Saturday, 25 April 2020 at 15:17:35 UTC, Steven Schveighoffer wrote:
>>> I propose a function any which takes a range and returns true if any element matches the provided one. And another one all(val) which does the same if all are the value. This gives us maximum flexibility.
>> 
>> Looks like std.algorithm.any and std.algorithm.all can already do this.
>
> Nice! The only thing I would say is I don't want to have a giant nest of subcalls for something like this, which can be done with one foreach loop. I'll have to look at the implementation.
>
> -Steve

If you need this implementation to be extended please drop me a line.

On Saturday, 25 April 2020 at 10:11:08 UTC, Stefan Koch wrote:
> ...
> 
> dmd fresh from walters branch release build with ldmd(ldc) 1.20
> time:
> 0m0.230s
> time for a fresh dmd build under the same conditions with that patch reverted:
> 0m0.270s
> time for doing it with our "..." patch:
> 0m0.030s
>
> these numbers are just a best out of 3 measurement so please only see them as a rough guide.

Sidenote: may I recommend the excellent tool multitime (/usr/bin/time with multiple passes): https://tratt.net/laurie/src/multitime/ , which gives you mean, median and standard deviation, automated multiple runs, and even interleaving of different commands to account for system load.

On Friday, 24 April 2020 at 20:23:09 UTC, Walter Bright wrote:
> On 4/24/2020 1:54 AM, Simen Kjærås wrote:
>>> Operator overloads don't change it.
>> 
>> Sure they do - just think of expression templates.
>
> We're not adding features to support expression templates with tuples.
>
> ETs were "discovered" in the early aughts, and caused great excitement in the C++ community. Lots of articles, presentations, and projects were done using ETs.
>
> Then ... nothing. They just vanished from the conversation. The problem is they were ugly, clumsy, incomprehensible to debug, incredibly slow to compile, did not work at scale (blowing up the compilers) and impossible to work with if you weren't an expert.
>
> They're a failed experiment.

ETs are very much alive in C++. Both Eigen and Boost.Spirit are popular libraries, and this despite the colossal hit to compile-times.

On Monday, 27 April 2020 at 12:08:11 UTC, Atila Neves wrote:
> [snip]
>
> ETs are very much alive in C++. Both Eigen and Boost.Spirit are popular libraries, and this despite the colossal hit to compile-times.

Eigen is also a dependency in a number of other libraries. When people really need extra performance, they will tolerate longer compile-times until they have a better solution. The error messages are not fun.

On Monday, 27 April 2020 at 12:08:11 UTC, Atila Neves wrote:
>
> ETs are very much alive in C++. Both Eigen and Boost.Spirit are popular libraries, and this despite the colossal hit to compile-times.

One of the good things about D is that Boost is not in the ecosystem.
Rather we have phobos which tries to come close sometimes.

On Monday, 27 April 2020 at 13:02:03 UTC, jmh530 wrote:
> On Monday, 27 April 2020 at 12:08:11 UTC, Atila Neves wrote:
>> [snip]
>>
>> ETs are very much alive in C++. Both Eigen and Boost.Spirit are popular libraries, and this despite the colossal hit to compile-times.
>
> Eigen is also a dependency in a number of other libraries. When people really need extra performance, they will tolerate longer compile-times until they have a better solution. The error messages are not fun.

I know. Eigen is literally the reason why I can't convince any friends who work at CERN to try D. My dream would be to have dpp somehow enable calling it from D, but I'm not sure that'll ever be possible.

On 4/27/2020 7:41 AM, Atila Neves wrote:
> On Monday, 27 April 2020 at 13:02:03 UTC, jmh530 wrote:
>> On Monday, 27 April 2020 at 12:08:11 UTC, Atila Neves wrote:
>>> [snip]
>>>
>>> ETs are very much alive in C++. Both Eigen and Boost.Spirit are popular libraries, and this despite the colossal hit to compile-times.
>>
>> Eigen is also a dependency in a number of other libraries. When people really need extra performance, they will tolerate longer compile-times until they have a better solution. The error messages are not fun.
> 
> I know. Eigen is literally the reason why I can't convince any friends who work at CERN to try D. My dream would be to have dpp somehow enable calling it from D, but I'm not sure that'll ever be possible.

Actually, you can write expression templates in D (I've done it as a demo). But it is a bit more limited in D because D doesn't allow separate overloads for < <= > >=, for example.

A far as Boost Spirit goes, more than one person has made a D parser generator using mixins that is far better.

On Mon, Apr 27, 2020 at 03:15:53PM -0700, Walter Bright via Digitalmars-d wrote: [...]
> Actually, you can write expression templates in D (I've done it as a demo).  But it is a bit more limited in D because D doesn't allow separate overloads for < <= > >=, for example.
> 
> A far as Boost Spirit goes, more than one person has made a D parser generator using mixins that is far better.

Operator overload abuse of the kind Boost Spirit does makes me cringe. Not only it uglifies the code, it's also unnatural to write because the abused built-in operators don't even look like how traditional grammar operators would be written, making it unnatural to read in addition to be a pain to write. (And don't even talk about the nastiness of debugging that mess, with reams of errors each of which occupies multiple pages of unreadably-long nested template symbols.)

D's recommended approach of using a string mixin or string argument to a CTFE generator function is *so* much better. You can write normal code that generates a parser instead of deeply-nested recursive templates, and you can use natural notation instead of contorting everything to fit into built-in operators that have been shoehorned into purposes utterly alien to their original design.

On a larger-picture note, I think that in the long term the way of progress lies with first-class types manipulated by CTFE functions that treats them like "runtime" values, that Stefan has been proposing. While templates are Turing-complete, and in theory can express all possible compile-time manipulations you might want to do, actually doing so is like trying to write a GUI application in lambda calculus. It's *possible* but extremely tedious, error-prone, and just overall painful to write, maintain, and debug.  (Not to mention consumes gobs of resources at compile-time and causing insane compiler slowdowns.)  Being able to manipulate types and arrays of types (tuples, and the rest of its ilk) will bring D meta-programming into a whole new level that will outpace every other language capable of meta-programming that I know of. (Maybe besides Lisp macros. :P)  Couple this with newCTFE, and I think we have a killer combo.


T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte

A while back on IRC we came up with an idea for first class types.

https://gist.github.com/rikkimax/046fb4451e8cbac354ecb292f9a76798#file-first-class-types-md

Basically just an extension of TypeInfo.

On Tuesday, 28 April 2020 at 01:20:50 UTC, rikki cattermole wrote:
> A while back on IRC we came up with an idea for first class types.
>
> https://gist.github.com/rikkimax/046fb4451e8cbac354ecb292f9a76798#file-first-class-types-md
>
> Basically just an extension of TypeInfo.

I was going for a solution which leaves most of the syntax as is. All that requires is slightly special handling of most tuple returning __traits, as well as a way to create "assignable" tuples.
(Which are not actually tuples but rather references to tuples)