www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cppfront : A new syntax for C++

reply Tejas <notrealemail gmail.com> writes:
https://github.com/hsutter/cppfront

People working towards syntax improvements as well to C++ now, 
which they believe will pave the way for semantic improvements 
that break backwards compatibility with C++

Taken from the repo:


 **Important disclaimer**: This isn't about 'just a pretty 
 syntax,' it's about fixing semantics. The unambiguous 
 alternative syntax is just a means to an end, a gateway that 
 lets us access a new open space beyond it — and sure, if we 
 build a gate, then the gate ought to look nice too, so we build 
 it with good boards and paint it nice colors. But the gate is 
 the doorway, the portal, not the goal... the real payoff is 
 gaining access to that new open space in C++ that's free of 
 backward source compatibility constraints where we can 
 (finally) fix semantics — order-independence, great defaults, 
 regular composable semantic meanings — as we see fit.
Sep 17 2022
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++

 Taken from the repo:


 **Important disclaimer**: This isn't about 'just a pretty 
 syntax,' it's about fixing semantics. The unambiguous 
 alternative syntax is just a means to an end, a gateway that 
 lets us access a new open space beyond it — and sure, if we 
 build a gate, then the gate ought to look nice too, so we 
 build it with good boards and paint it nice colors. But the 
 gate is the doorway, the portal, not the goal... the real 
 payoff is gaining access to that new open space in C++ that's 
 free of backward source compatibility constraints where we can 
 (finally) fix semantics — order-independence, great defaults, 
 regular composable semantic meanings — as we see fit.




That's great to hear, C++ is a giant and uncontrollable mess

Already looks better than Carbon

How funny: 
https://github.com/hsutter/cppfront#2021-is-as-and-pattern-matching

https://github.com/dlang/vision-document#other (in #other, 
unfortunately)
Sep 17 2022
parent reply Tejas <notrealemail gmail.com> writes:
On Saturday, 17 September 2022 at 11:41:18 UTC, ryuukk_ wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++

 Taken from the repo:


 [...]




 That's great to hear, C++ is a giant and uncontrollable mess

 Already looks better than Carbon

 How funny: 
 https://github.com/hsutter/cppfront#2021-is-as-and-pattern-matching

 https://github.com/dlang/vision-document#other (in #other, 
 unfortunately)


I'm just worried about D's place in this world where there's 
Carbon, C++26, Rust, Nim and now this 😔
Sep 17 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 17 September 2022 at 11:55:16 UTC, Tejas wrote:

 On Saturday, 17 September 2022 at 11:41:18 UTC, ryuukk_ wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ 
 now, which they believe will pave the way for semantic 
 improvements that break backwards compatibility with C++

 Taken from the repo:


 [...]




 That's great to hear, C++ is a giant and uncontrollable mess

 Already looks better than Carbon

 How funny: 
 https://github.com/hsutter/cppfront#2021-is-as-and-pattern-matching

 https://github.com/dlang/vision-document#other (in #other, 
 unfortunately)


 I'm just worried about D's place in this world where there's 
 Carbon, C++26, Rust, Nim and now this 😔


You forgot about:

  - Val, https://www.val-lang.dev from Dave Abrahms and Sean Parent

  - Verona, https://microsoft.github.io/verona/ from Microsoft 
Research

  - Odin, https://odin-lang.org/ already used in the games 
industry, via EmberGen


features (and AOT story in Java/.NET case), so that their need 
for C and C++ gets reduced.

With Val, Carbon and now Cppfront coming out of the C++ community 
itself, we are at an inflection point, I bet C++26 might be the 
latest big revision.

So yeah, the competition to D is getting stiffer, and it is a 
question of how many of those C++ disillusioned souls might 
eventually find a home in D.
Sep 17 2022
next sibling parent Tejas <notrealemail gmail.com> writes:
On Saturday, 17 September 2022 at 14:57:40 UTC, Paulo Pinto wrote:

 On Saturday, 17 September 2022 at 11:55:16 UTC, Tejas wrote:

 On Saturday, 17 September 2022 at 11:41:18 UTC, ryuukk_ wrote:

 [...]


 I'm just worried about D's place in this world where there's 
 Carbon, C++26, Rust, Nim and now this 😔


 You forgot about:

  - Val, https://www.val-lang.dev from Dave Abrahms and Sean 
 Parent

  - Verona, https://microsoft.github.io/verona/ from Microsoft 
 Research

  - Odin, https://odin-lang.org/ already used in the games 
 industry, via EmberGen


 features (and AOT story in Java/.NET case), so that their need 
 for C and C++ gets reduced.

 With Val, Carbon and now Cppfront coming out of the C++ 
 community itself, we are at an inflection point, I bet C++26 
 might be the latest big revision.

 So yeah, the competition to D is getting stiffer, and it is a 
 question of how many of those C++ disillusioned souls might 
 eventually find a home in D.


Val and Verona are extremely early stage though, no? But that 
might not be the case ~2025...

Didn't know Odin was already getting used in industry, pretty 
cool...

Hope we manage to get our stuff together and not just survive, 
but thrive in this decade
Sep 17 2022
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 17 September 2022 at 14:57:40 UTC, Paulo Pinto wrote:

 With Val, Carbon and now Cppfront coming out of the C++ 
 community itself, we are at an inflection point, I bet C++26 
 might be the latest big revision.


I don't know. I think C++ has become fairly well-rounded now that 
clang is catching up on C++20. At this point it will take a while 
for the C++ community to make good use of C++'s take on 
coroutines and concepts. It would probably be a bad idea to 
continue to push in more big features. Some smaller ones like 
SIMD are missing still. But in the longer term I think we will 
see more standardized hardware oriented features related to 
parallelism, co-processors etc. I suspect Intel and AMD will have 
to do something to ensure their own relevance in the long term, 
and C/C++ is where they can make software "hardware dependent". 
So in that sense C/C++ has a guaranteed long life span. System 
programming isn't just market driven, it is also hardware driven.
Sep 17 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 17 September 2022 at 22:27:32 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 17 September 2022 at 14:57:40 UTC, Paulo Pinto 
 wrote:

 With Val, Carbon and now Cppfront coming out of the C++ 
 community itself, we are at an inflection point, I bet C++26 
 might be the latest big revision.


 I don't know. I think C++ has become fairly well-rounded now 
 that clang is catching up on C++20. At this point it will take 
 a while for the C++ community to make good use of C++'s take on 
 coroutines and concepts. It would probably be a bad idea to 
 continue to push in more big features. Some smaller ones like 
 SIMD are missing still. But in the longer term I think we will 
 see more standardized hardware oriented features related to 
 parallelism, co-processors etc. I suspect Intel and AMD will 
 have to do something to ensure their own relevance in the long 
 term, and C/C++ is where they can make software "hardware 
 dependent". So in that sense C/C++ has a guaranteed long life 
 span. System programming isn't just market driven, it is also 
 hardware driven.


Clang catching up, that is news to me, specially in what concerns 
modules.

Herb Sutter clearly address the issues the need to fix C and C++ 
due to US  new cyber security bill where it explicitly calls out 
for software no longer being written in C and C++, unless there 
is no other option.

Eventually using unsafe languages will require clearance from a 
cyber security government agency.
Sep 18 2022
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 18 September 2022 at 08:47:24 UTC, Paulo Pinto wrote:

 Herb Sutter clearly address the issues the need to fix C and 
 C++ due to US  new cyber security bill where it explicitly 
 calls out for software no longer being written in C and C++, 
 unless there is no other option.

 Eventually using unsafe languages will require clearance from a 
 cyber security government agency.


Links?
Sep 18 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 18 September 2022 at 09:25:25 UTC, Nicholas Wilson 
wrote:

 On Sunday, 18 September 2022 at 08:47:24 UTC, Paulo Pinto wrote:

 Herb Sutter clearly address the issues the need to fix C and 
 C++ due to US  new cyber security bill where it explicitly 
 calls out for software no longer being written in C and C++, 
 unless there is no other option.

 Eventually using unsafe languages will require clearance from 
 a cyber security government agency.


 Links?


His CppCon talk.

https://youtu.be/CzuR0Spm0nA

The Atlantic Council report on the bill,

https://www.atlanticcouncil.org/content-series/buying-down-risk/memory-safety/
Sep 18 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 9/18/22 03:24, Paulo Pinto wrote:

 On Sunday, 18 September 2022 at 09:25:25 UTC, Nicholas Wilson wrote:



 Links?


 His CppCon talk.

 https://youtu.be/CzuR0Spm0nA

 The Atlantic Council report on the bill,

 


https://www.atlanticcouncil.org/content-series/buying-down-risk/memory-safety/

Thank you! This is one of the reasons I love these forums. I find 
valuable fuel just when I am tupdating my D introduction slides. :)

Ali
Sep 18 2022
parent Tejas <notrealemail gmail.com> writes:
On Sunday, 18 September 2022 at 14:45:54 UTC, Ali Çehreli wrote:

 On 9/18/22 03:24, Paulo Pinto wrote:

 On Sunday, 18 September 2022 at 09:25:25 UTC, Nicholas Wilson


 wrote:


 Links?


 His CppCon talk.

 https://youtu.be/CzuR0Spm0nA

 The Atlantic Council report on the bill,

 


 https://www.atlanticcouncil.org/content-series/buying-down-risk/memory-safety/

 Thank you! This is one of the reasons I love these forums. I 
 find valuable fuel just when I am tupdating my D introduction 
 slides. :)

 Ali



respect to C++, then D most definitely fits the bill as well 
despite the GC
Sep 18 2022
prev sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 18 September 2022 at 10:24:38 UTC, Paulo Pinto wrote:

 His CppCon talk.

 https://youtu.be/CzuR0Spm0nA

 The Atlantic Council report on the bill,

 https://www.atlanticcouncil.org/content-series/buying-down-risk/memory-safety/


A big part of the first section is some kind of political talk 
how they use the strategy of early 1900 century communist 
intellectuals in order to advance C++. Good indication that 
something is not quite right.

Then I skimmed through Sutters CppFront presentation and quickly 
realized that it doesn't help much at all. Rather I must learn 
another syntax in addition to learning the vast C++ language. All 
this time spent on trying "fix" C++, think what you could have 
done with a new language or an existing sane one.

I have probably mentioned, if you see modern C++, don't walk 
away, run away. Now it's more I need a really fast vehicle.

What's good is that the world has moved on and there are plenty 
of alternatives and more a popping up all the time. There is no 
excuse for using C++ anymore for new projects. Thank you for 
giving us these jump scares now and then.
Sep 18 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 18 September 2022 at 15:16:20 UTC, IGotD- wrote:

 Then I skimmed through Sutters CppFront presentation and 
 quickly realized that it doesn't help much at all.


It is just an experiment in the initial stage, clearly quite 
personal at this point.

If he gets arenas right then that could be a significant 
improvement. Enough to get  some adoption.


 All this time spent on trying "fix" C++, think what you could 
 have done with a new language or an existing sane one.


People create new languages all the time, most die off, stagnates 
and simply fail to reach critical mass.


 What's good is that the world has moved on and there are plenty 
 of alternatives and more a popping up all the time.


The alternatives are most likely competing with each other and to 
a lesser extent affecting C++ in the short term.

Many alternatives make it harder to build a competing eco-system. 
So it isn’t obvious that this is a disadvantage for C++. If there 
was a single strong contender for hardware-oriented programming 
then it might hurt C++, but right now there is none.
Sep 18 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 19 September 2022 at 06:44:05 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 18 September 2022 at 15:16:20 UTC, IGotD- wrote:

 Then I skimmed through Sutters CppFront presentation and 
 quickly realized that it doesn't help much at all.


 It is just an experiment in the initial stage, clearly quite 
 personal at this point.

 If he gets arenas right then that could be a significant 
 improvement. Enough to get  some adoption.


 All this time spent on trying "fix" C++, think what you could 
 have done with a new language or an existing sane one.


 People create new languages all the time, most die off, 
 stagnates and simply fail to reach critical mass.


 What's good is that the world has moved on and there are 
 plenty of alternatives and more a popping up all the time.


 The alternatives are most likely competing with each other and 
 to a lesser extent affecting C++ in the short term.

 Many alternatives make it harder to build a competing 
 eco-system. So it isn’t obvious that this is a disadvantage for 
 C++. If there was a single strong contender for 
 hardware-oriented programming then it might hurt C++, but right 
 now there is none.


Other than C that is.

And eventually everyone sending patches to the Linux kernel, 
might as well brush up their Rust skills.

https://www.zdnet.com/article/linus-torvalds-rust-may-make-it-into-the-next-linux-kernel-after-all/
Sep 19 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 19 September 2022 at 07:43:24 UTC, Paulo Pinto wrote:

 Other than C that is.


Right, but CPU/SoC manufacturers have some interest in getting 
support for their hardware in LLVM/Clang or the GCC suite, so for 
the less esoteric devices C and C++ can be considered to be the 
same (same or similar compiler core, with some configuration 
differences).


 And eventually everyone sending patches to the Linux kernel, 
 might as well brush up their Rust skills.


Sure, but I perceive Rust as more of a high level approach with 
functional leanings, that also allows some low level programming. 
I guess one motivation for Carbon is to take that extra step 
towards a more hardware oriented vantage point with eco system 
backwards compatibility, in comparison with Rust. Still, it is 
not clear what Carbon will become like at this point and it seems 
to take in quite a bit of high level influence from Rust, ML and 
other such languages with a "high" abstraction level. I also am 
not sure if there is enough people with a focus on embedded and 
hardware that are engaging with the Carbon design process, which 
is a pity since the process is open for anyone to join.

Most system languages seem to suffer from not taking in the full 
use-case spectrum from the start. That appears to be an obstacle 
for most alternative system programming platforms, including D. 
It turns out that it is very difficult to change course later, as 
we can see with D and memory allocation (process, culture and 
design-dependencies appears to make late changes very difficult 
on a "social" level).
Sep 19 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 18 September 2022 at 08:47:24 UTC, Paulo Pinto wrote:

 Clang catching up, that is news to me, specially in what 
 concerns modules.


Slowly catching up then :-). The things I care the most about are 
in.
Sep 18 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 18 September 2022 at 09:51:52 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 18 September 2022 at 08:47:24 UTC, Paulo Pinto wrote:

 Clang catching up, that is news to me, specially in what 
 concerns modules.


 Slowly catching up then :-). The things I care the most about 
 are in.


Just like what Apple and Google care about is C++17 and nothing 
beyond that, meanwhile no compiler vendor selling C and C++ 
compilers based on clang forks seem to care about upstream ISO 
C++ compliance.

Hence my surprise about your remark regarding catching up.
Sep 18 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 18 September 2022 at 10:26:43 UTC, Paulo Pinto wrote:

 Just like what Apple and Google care about is C++17 and nothing 
 beyond that, meanwhile no compiler vendor selling C and C++ 
 compilers based on clang forks seem to care about upstream ISO 
 C++ compliance.

 Hence my surprise about your remark regarding catching up.


Sure, I care most about things that simplify the way I would 
write C++17ish code: concept, requires, span, char8_t, 
[[no_unique_address]], bitcast, feature test macros…

That feature test macro approach could turn into a sleeping pill, 
though. I am in favour of it, but it puts less pressure on 
compiler vendors. It allows programmers to start using new 
features with a fall-back, but it also allows vendor to say "it 
isn't quite done, but you can use that compatibility layer 
library over there".

Clang does fairly well with C++23, so that is a bit odd, perhaps. 
I guess some C++20 features are hard to work into their internal 
representation (IIRC basically an explicit AST).

https://en.cppreference.com/w/cpp/compiler_support/20
https://en.cppreference.com/w/cpp/compiler_support/23
Sep 18 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2022 1:47 AM, Paulo Pinto wrote:

 Eventually using unsafe languages will require clearance from a cyber security 
 government agency.


This trend is why D is steadily moving towards 100% memory safety.
Sep 19 2022
parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 19 September 2022 at 08:59:44 UTC, Walter Bright wrote:

 On 9/18/2022 1:47 AM, Paulo Pinto wrote:

 Eventually using unsafe languages will require clearance from 
 a cyber security government agency.


 This trend is why D is steadily moving towards 100% memory 
 safety.


Modulo bugs and undefined behaviour on assert failure with 
`-release`, We already have it with `-preview=dip1000` turned on. 
I think.

I think you mean memory safe RAII and reference counting. DIP1000 
enables limited forms of those, but in practice one still tends 
to be stuck mostly with the GC, static memory and the stack.
Sep 19 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/19/2022 2:30 AM, Dukc wrote:

 I think you mean memory safe RAII and reference counting. DIP1000 enables 
 limited forms of those, but in practice one still tends to be stuck mostly
with 
 the GC, static memory and the stack.


 live, which deals with memory allocation, is the step after DIP1000.
Sep 19 2022
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 19.09.22 20:41, Walter Bright wrote:

 On 9/19/2022 2:30 AM, Dukc wrote:

 I think you mean memory safe RAII and reference counting. DIP1000 
 enables limited forms of those, but in practice one still tends to be 
 stuck mostly with the GC, static memory and the stack.


 
  live, which deals with memory allocation, is the step after DIP1000.
 


(It's a linting tool and it does nothing to enhance  safe safety 
guarantees because it is a function attribute.)
Sep 19 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 17 September 2022 at 11:55:16 UTC, Tejas wrote:

 On Saturday, 17 September 2022 at 11:41:18 UTC, ryuukk_ wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ 
 now, which they believe will pave the way for semantic 
 improvements that break backwards compatibility with C++

 Taken from the repo:


 [...]




 That's great to hear, C++ is a giant and uncontrollable mess

 Already looks better than Carbon

 How funny: 
 https://github.com/hsutter/cppfront#2021-is-as-and-pattern-matching

 https://github.com/dlang/vision-document#other (in #other, 
 unfortunately)


 I'm just worried about D's place in this world where there's 
 Carbon, C++26, Rust, Nim and now this 😔


Indeed, simply asking for .Enum was met with negativity, so i 
don't see our fate improving anytime soon
Sep 17 2022
parent Nick Treleaven <nick geany.org> writes:
On Saturday, 17 September 2022 at 17:47:57 UTC, ryuukk_ wrote:

 Indeed, simply asking for .Enum was met with negativity, so i 
 don't see our fate improving anytime soon


Language design is about trade-offs, expect people to disagree 
about things. That doesn't mean it's not worth trying to make 
improvements. There is a DIP PR for `$member` (`.member` is 
ambiguous).
Sep 17 2022
prev sibling parent reply claptrap <clap trap.com> writes:
On Saturday, 17 September 2022 at 11:55:16 UTC, Tejas wrote:

 On Saturday, 17 September 2022 at 11:41:18 UTC, ryuukk_ wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront



 https://github.com/dlang/vision-document#other (in #other, 
 unfortunately)


 I'm just worried about D's place in this world where there's 
 Carbon, C++26, Rust, Nim and now this 😔


It'll be ironic if the thing that Walter said will kill C 
actually ends up killing D cause it basically put everything else 
on the back burner for 10 years.

Is DIP1000 the new Phobos vs Tango?
Sep 17 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/17/2022 4:32 PM, claptrap wrote:

 Is DIP1000 the new Phobos vs Tango?


I recently went through all the DIP1000 bugs in bugzilla. Many were pronounced 
in the n.g. as DIP1000 killers, but they have PRs now to fix them.

DIP1000 is in good shape.


 put everything else on the back burner for 10 years


Ignoring everything else we've done.
Sep 19 2022
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 19 September 2022 at 09:03:42 UTC, Walter Bright wrote:

 On 9/17/2022 4:32 PM, claptrap wrote:

 Is DIP1000 the new Phobos vs Tango?


 I recently went through all the DIP1000 bugs in bugzilla. Many 
 were pronounced in the n.g. as DIP1000 killers, but they have 
 PRs now to fix them.

 DIP1000 is in good shape.


 put everything else on the back burner for 10 years


 Ignoring everything else we've done.


Cool, please focus on getting Dip1000 finalized ❤️

D will prevail!
Sep 19 2022
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++


When C++ compile times aren't long enough, let's make them longer.

My first question that comes to mind, why compile this to C++ 
when you have C which is much faster and you can do the same 
thing. Essentially this is what Nim does which has full meta 
programming that can be compiled to C.

C++, isn't holding up anymore and is too simple let's make C++11
Let's make C++11 modern -> C++20
C++20 has a complicated and ugly syntax, let's fix that with 
CppFront.
... and it just goes on, taint it up, taint it up.

Even more funny is that this is from Herb Sutter which is one of 
the biggest influencers of "modern C++".
Sep 17 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 17 September 2022 at 15:56:54 UTC, IGotD- wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 ......





For D, The existing features need to be repaired completely. 
Don't try to be too fast.
`One hundred percent` is better than `three 95 percent`.
Sep 17 2022
prev sibling parent German Diago <german.diago cppmaster.net> writes:
On Saturday, 17 September 2022 at 15:56:54 UTC, IGotD- wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++


 When C++ compile times aren't long enough, let's make them 
 longer.


This is the wrong judgement to do (about compile times). Compile 
times with modules are *shorter*. Cpp2 pushes for modules, not 
for include, but pure modules.

Besides that, there are things such as tuples (multiple return 
values) done without templates, which avoids instantiation.

Also, take into account that cppfront being a preprocessor is an 
implementation detail to easily be able to mix and match cpp/cpp2 
and that some day it could become a full-fledged compiler. Cpp2 
is thought for transition to pure cpp2 but 100% compatible. This 
means that preprocessing by lowering is a technique, but not the 
only technique.

Greetings.
Sep 24 2022
prev sibling next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
All these new better C/C++ that are popping out is the clear 
signal that people are still interested in system programming and 
are not happy about the current solutions

If D has proper allocator API and an allocator driven STD instead 
of just the GC, i'm pretty sure it would have been mentioned more 
in all these project papers instead of being simply just IGNORED
Sep 19 2022
prev sibling parent reply Ben Jones <fake fake.fake> writes:
On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++

 Taken from the repo:


 [...]




D (slide) shoutout in Herb's talk: 
https://youtu.be/ELeZAKCN4tY?t=2755
Sep 19 2022
parent Tejas <notrealemail gmail.com> writes:
On Monday, 19 September 2022 at 19:02:23 UTC, Ben Jones wrote:

 On Saturday, 17 September 2022 at 11:08:37 UTC, Tejas wrote:

 https://github.com/hsutter/cppfront

 People working towards syntax improvements as well to C++ now, 
 which they believe will pave the way for semantic improvements 
 that break backwards compatibility with C++

 Taken from the repo:


 [...]




 D (slide) shoutout in Herb's talk: 
 https://youtu.be/ELeZAKCN4tY?t=2755


You are much much more charitable than me, calling that lightly 
shaded arrow a D shoutout.
Sep 19 2022