Of possible interest:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf

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

Great, let's make c++ more confusing to newbies.

-Alex

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:])>();

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

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

Thank you for posting this. Oh my god, let's hope this goes through and let C++ destroy itself. It seems like the C++ maintainers are becoming more and more obsessed with colons.

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

"Readability. Obviously, we’d like our programs to be readable. We want syntax that is both visually distinctive yet comprehensible."

Can anyone more experienced with C++ confirm that this is in any way readable and easy to understand? Because my definition of "readability" appears to be vastly different, especially when I imagine it being used alongside the rest of C++'s symbol spam.

"f<([:Refl:])>();"

wat

"(: R :). Looks like smiley faces"

But apparently "[:" and ":]" don't. Part of me feels like the designer(s) really wanted to use square brackets for that extra *artistic touch*.

I don't really have anything constructive to say about this (presumably) draft proposal, because the actual feature itself is of course pretty useful, and I'm not really qualified to say whether this proposal is a good fit or not. But why is it that C++ uses such unusual syntax for everything?

On Monday, 22 February 2021 at 18:01:34 UTC, SealabJaster 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

Also for that first example under 5.3.3, I hope that they made a mistake when writing it, because I really don't see how `cout << %x;` prints the value of "V" while `cout << t.%x;` prints "t.m". I ask this because I have a slight concern that this might actually be intentional.

On Monday, 22 February 2021 at 16:43:34 UTC, 12345swordy 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
>
> Great, let's make c++ more confusing to newbies.
>
> -Alex

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

-Alex

On Monday, 22 February 2021 at 16:54:31 UTC, IGotD- wrote:
> Oh my god, let's hope this goes through and let C++ destroy itself.

I can't agree with this wish - not everybody can switch. If something like this goes through it'd only make life more difficult to those who don't have the luxury of D (or Rust, Go, Nim, etc.). I believe C++ is still an improvement over C (at least if you don't go crazy with all the complex features).

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.

On Mon, Feb 22, 2021 at 07:27:29PM +0000, Dukc via Digitalmars-d wrote:
> On Monday, 22 February 2021 at 16:54:31 UTC, IGotD- wrote:
> > Oh my god, let's hope this goes through and let C++ destroy itself.
> 
> I can't agree with this wish - not everybody can switch. If something like this goes through it'd only make life more difficult to those who don't have the luxury of D (or Rust, Go, Nim, etc.).

That would perhaps put more pressure on C++ devs to switch to a saner language! ;-)


> I believe C++ is still an improvement over C (at least if you don't go crazy with all the complex features).

That is precisely the problem: all the complex features are still there, beckoning every new hire to use them as a quick-fix to make a release deadline.  Unless you keep a very tight control over what features can be used -- essentially balkanizing the language, which has already happened for at least a decade, probably longer -- the codebase becomes a gigantic, unmaintainable mess.

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++.


> 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


T

-- 
Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton

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.