On Monday, 22 February 2021 at 21:16:07 UTC, H. S. Teoh wrote:
> That would perhaps put more pressure on C++ devs to switch to a saner language! ;-)

But who would maintain the C++ programs then? There may be a reasonable case to discourage new projects in C++, but's that's hardly the same as trying to kill C++ programming.

Until we can automatically transpile everything I quess.


> Years ago, I worked in a team project where there was a C++-based infrastructure so fancy and over-engineered, that after a while nobody knew how to use it properly and started spending more time working around it than using it.  Eventually, we ditched the C++ portion completely and rewrote it from scratch in C.  It was a refreshing change.  C's relative dearth of features was certainly limiting, but limitation is not a bad thing in a team where people are constantly coming and going. No matter how horribly the code devolved, there was still only a small set of features it could abuse, and the scope of abuse is well-known and manageable.  It wasn't *enjoyable* to go back to C per se (D takes the cake on that one :-D), but it was definitely better than drowning in the ocean of badly-interacting misfeatures that is C++.

Hmm, I see. The engineer in me says it's foolish to ditch all C++, keep the function overloading and simple templates at least (I'm thinking something like `T binaryFun<T>(T arg1, T arg2)`). But I can kinda see that rules like that might have weaker authority than a simple language change. I'm still suspicious about the tradeoff you made but at least I see potential reason to accept it.

>
>
>> But I too kind of fail to see how `f(...[:tuple:]..., a, b)` would cut it
>> when `tuple.expand.f(a,b)` has been possible in "another language" for like
>> 10 years.
>
> That's why C++'s early death would do everyone some good. Maybe some of the survivors would discover D. :-D

I meant that I don't see how it would cut to add as a new language feature. But for the hapless programmer who is down to either it, the C preprocessor, or copypasta, it just might make sense IMO. Just barely, and just maybe.

On Monday, 22 February 2021 at 21:34:47 UTC, Max Haughton wrote:
> On Monday, 22 February 2021 at 16:27:49 UTC, Andrei Alexandrescu wrote:
>> Of possible interest:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf
>
> Exposing reflection information via CTFE seems like a much more workable solution - i.e. you just write regular D code. This is what Stefan's work effectively culminates in.

Or, in other words: procedural macros. (Shh, don't tell Walter.)

On Mon, Feb 22, 2021 at 09:47:48PM +0000, Dukc via Digitalmars-d wrote:
> On Monday, 22 February 2021 at 21:16:07 UTC, H. S. Teoh wrote:
> > That would perhaps put more pressure on C++ devs to switch to a saner language! ;-)
> 
> But who would maintain the C++ programs then? There may be a reasonable case to discourage new projects in C++, but's that's hardly the same as trying to kill C++ programming.

Relax, nobody is "trying to kill C++ programming". But the more the C++ committee tries to add more fat to an already overweight beast of a language, its inevitable demise draws nearer, and bystanders like myself enjoy speculating on the benefits that everyone would enjoy once the beast is finally, fully, dead.


> Until we can automatically transpile everything I quess.

I don't think you need to worry; the industry has enough C++ code around that it will last for a *long* time yet.  And if the beast ever actually dies, I'm sure more than just a handful of clever heads would come up with a good way of migrating everything over. (More like, everyone and their neighbour's dog will invent a way, of which may be a handful will survive the test of real-world code and become widely disseminated as the solution(s) to the migration problem.)


> > Years ago, I worked in a team project where there was a C++-based infrastructure so fancy and over-engineered, that after a while nobody knew how to use it properly and started spending more time working around it than using it.  Eventually, we ditched the C++ portion completely and rewrote it from scratch in C.  It was a refreshing change.  C's relative dearth of features was certainly limiting, but limitation is not a bad thing in a team where people are constantly coming and going. No matter how horribly the code devolved, there was still only a small set of features it could abuse, and the scope of abuse is well-known and manageable.  It wasn't *enjoyable* to go back to C per se (D takes the cake on that one :-D), but it was definitely better than drowning in the ocean of badly-interacting misfeatures that is C++.
> 
> Hmm, I see. The engineer in me says it's foolish to ditch all C++,
> keep the function overloading and simple templates at least (I'm
> thinking something like `T binaryFun<T>(T arg1, T arg2)`).

Some of the programmers on the team were so badly burned by the experience that they flinch at the mere sight of templates at a distance of 10 feet away.


> But I can kinda see that rules like that might have weaker authority than a simple language change.

We're talking about real world code here, written in a real company by real people (most of whom have moved on to better things) and running in real customer environments.  Experience has shown time and again that such "rules" do not work. Never did work. It's programming by convention, as Walter often refers to, and everyone knows what happens when the release deadline is looming and everyone has more on their plate than they could possibly hope to finish.  You just reach out and use whatever straw you could grasp to get it working and move on.  If a feature is in the language, people will use it. The boss isn't going to stop a release just because somebody broke the rules and as a result got the code working by the deadline. (As opposed to, y'know, sticking to the rules and *not* shipping on time.)

Besides, having features in the language that nobody ever uses is really pointless. Better throw it out and end up with a better, slimmer language.


> I'm still suspicious about the tradeoff you made but at least I see potential reason to accept it.
[...]

I wasn't the one who made the decision.  If it were up to me, I'd have stuck with C++ somehow. But I can totally sympathize with why the PTB chose to ditch it.  It's hard not to sympathize when I've had the dubious privilege of writing a last-minute hack function call that involved 6 layers of abstraction, one of which involves an RPC bridge that uses fwrite, fread, and a temporary file in order to bridge the gap between the C++ and non-C++ parts of the code. (You *know* something has gone horribly wrong when the act of making a function call involves disk I/O and a temporary file (a *hard-coded* one...). And that's on top of several other layers of marshalling/unmarshalling.  Don't ask, you do *not* want to know.)

The day we finally could delete the entire C++ branch of the source there was a veritable celebration. We typed every `rm -rf` command with relish and exquisite delight. :-P


T

-- 
Why do conspiracy theories always come from the same people??

On Monday, 22 February 2021 at 21:59:41 UTC, Paul Backus wrote:
> On Monday, 22 February 2021 at 21:34:47 UTC, Max Haughton wrote:
>> On Monday, 22 February 2021 at 16:27:49 UTC, Andrei Alexandrescu wrote:
>>> Of possible interest:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf
>>
>> Exposing reflection information via CTFE seems like a much more workable solution - i.e. you just write regular D code. This is what Stefan's work effectively culminates in.
>
> Or, in other words: procedural macros. (Shh, don't tell Walter.)

They aren't macros though - at least in my mind a macro is effectively a shortcut into the bowels of the compiler whereas in this case the compiler wouldn't care what you do with the information after it gives it to you since it's just regular D code.

On 23/02/2021 7:22 AM, 12345swordy wrote:
> Oh great! The named parameter proposal for c++ is got to be the worst version of named parameters that I ever seen!
> https://groups.google.com/a/isocpp.org/g/std-proposals/c/3dUkwyp2Ie4/m/rZ8dgxVlCgAJ

They really went with the kitchen sink approach didn't they?
Yikes.

On Monday, 22 February 2021 at 23:32:39 UTC, Max Haughton wrote:
> On Monday, 22 February 2021 at 21:59:41 UTC, Paul Backus wrote:
>> On Monday, 22 February 2021 at 21:34:47 UTC, Max Haughton wrote:
>>> On Monday, 22 February 2021 at 16:27:49 UTC, Andrei Alexandrescu wrote:
>>>> Of possible interest:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf
>>>
>>> Exposing reflection information via CTFE seems like a much more workable solution - i.e. you just write regular D code. This is what Stefan's work effectively culminates in.
>>
>> Or, in other words: procedural macros. (Shh, don't tell Walter.)
>
> They aren't macros though - at least in my mind a macro is effectively a shortcut into the bowels of the compiler whereas in this case the compiler wouldn't care what you do with the information after it gives it to you since it's just regular D code.

Aren't macros in Lisp just regular Lisp code, too? :)

As far as I'm concerned, a procedural macro is a function that

1. runs at compile time,
2. takes AST nodes as input, and
3. produces AST nodes as output.

Type functions fit those criteria perfectly. Currently, they only work on a subset of AST nodes (types), so they're not a *complete* implementation of procedural macros, but generalize them enough and that's what you'll get.

On Tue, Feb 23, 2021 at 12:35:31PM +1300, rikki cattermole via Digitalmars-d wrote:
> On 23/02/2021 7:22 AM, 12345swordy wrote:
> > Oh great! The named parameter proposal for c++ is got to be the worst
> > version of named parameters that I ever seen!
> > https://groups.google.com/a/isocpp.org/g/std-proposals/c/3dUkwyp2Ie4/m/rZ8dgxVlCgAJ
> 
> They really went with the kitchen sink approach didn't they? Yikes.

Seeing as this is C++ we're talking about, a kitchen sink approach doesn't surprise me. (Even if it does disgust me. :-D)


T

-- 
Life is too short to run proprietary software. -- Bdale Garbee

On Monday, 22 February 2021 at 23:44:45 UTC, Paul Backus wrote:
>
> As far as I'm concerned, a procedural macro is a function that
>
> 1. runs at compile time,
> 2. takes AST nodes as input, and
> 3. produces AST nodes as output.
>
> Type functions fit those criteria perfectly. Currently, they only work on a subset of AST nodes (types), so they're not a *complete* implementation of procedural macros, but generalize them enough and that's what you'll get.

Yes.

Given the collective experience that we've had with D's meta programming facilities it would be surprising if we could not imagine something significantly better at this point.  By "better" I mostly mean facilities that would allow us to write code that is more readable, more composable, more testable, and more easily debuggable than an equally performant solution using current practice.

I'm sympathetic to both type functions and MTVs (monadic type variables), CT type objects with actual memory footprint that function as compiler-guaranteed-safe cursors within the lazily realized dependent type space of a D program.

Beyond those two I know that Stefan, and from the above and earlier writings I expect Paul, have thought about more powerful yet still tractable capabilities.  It feels like we're within reach of a significant advance.

On Tuesday, 23 February 2021 at 05:17:04 UTC, Bruce Carneal wrote:
> On Monday, 22 February 2021 at 23:44:45 UTC, Paul Backus wrote:
>>
>> As far as I'm concerned, a procedural macro is a function that
>>
>> 1. runs at compile time,
>> 2. takes AST nodes as input, and
>> 3. produces AST nodes as output.
>>
>> Type functions fit those criteria perfectly. Currently, they only work on a subset of AST nodes (types), so they're not a *complete* implementation of procedural macros, but generalize them enough and that's what you'll get.
>
> Yes.
>
> Given the collective experience that we've had with D's meta programming facilities it would be surprising if we could not imagine something significantly better at this point.  By "better" I mostly mean facilities that would allow us to write code that is more readable, more composable, more testable, and more easily debuggable than an equally performant solution using current practice.
>
> I'm sympathetic to both type functions and MTVs (monadic type variables), CT type objects with actual memory footprint that function as compiler-guaranteed-safe cursors within the lazily realized dependent type space of a D program.
>
> Beyond those two I know that Stefan, and from the above and earlier writings I expect Paul, have thought about more powerful yet still tractable capabilities.  It feels like we're within reach of a significant advance.

I have been talking to Stefan quite a lot about typefunctions recently, I'm reasonably convinced they are the most natural proposal to explore for D at the moment.

One thing I have been toying with is calling them metafunctions instead since they clearly don't only consider types in the general case.


Having a well defined type hierarchy to represent the AST in a manner seperate to the actual compiler has an added benefit of making it trivial to write clean programs that analyse D code without bringing in the entire compiler or going without sema.

On Monday, 22 February 2021 at 16:47:13 UTC, bachmeier wrote:
> On Monday, 22 February 2021 at 16:27:49 UTC, Andrei Alexandrescu wrote:
>> Of possible interest:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf
>
> Good this is proposed for C++ and not for D. The complexity/benefit ratio of adding another meaning of ^ and [:refl:] is rather high. Citing * and & as models for ^ is reasonable only to someone that has not tried to teach others to program. At least to me, this is horrible:
>
> f<([:Refl:])>();

aka as
<:Rofl:> <º))))><

>
> In complete seriousness, it would be better to use emoji than to write things like that.