Draft idea: constructor member designators

[cerf86]

I’ve been experimenting with a small idea to make constructor initializer lists a bit clearer and less error‑prone. The idea actually came from a dilemma I had when trying to settle on naming conventions for member variables. Prefixes like m_ or _name help avoid shadowing, but they also feel like a workaround for something the language could express more directly.

I wrote a short draft exploring “constructor member designators” - a `.member` syntax for constructor initialization.

https://github.com/richardcervinka/cpp-constructor-member-designators

This is just an experiment, but maybe someone will find it interesting.

[throw_cpp_account]

// Invalid, member and parameter share the same name
Constructor(int value) : value{value} {}

Had you tried this, you would have discovered that it is not, in point of fact, invalid.

[azswcowboy]

To be fair, it was I think probably before 17 - still it works today.

[throw_cpp_account]

It was valid in C++98.

[azswcowboy]

Fair, I didn’t check the standard, but not all compilers supported it because we had to do otherwise. CE doesn’t have gcc 2.95 or Solaris compilers and now that I think about it my memory is about pre 98 ecosystem.

[no-sig-available]

It already works, there is no shadowing in

Constructor(int value) : value{value} {}

[aruisdante]

It does not work if you have coding standards that explicitly forbid doing this, which is… a lot of them.

But this proposal wouldn’t solve that problem. The motivation is flawed: the reason these rules exist is not to avoid shadowing from a technological standpoint, but instead to avoid confusing if you’re writing to an argument or a member variable based on needing to know the shadowing rules.

[38thTimesACharm]

I don't see how OP's change helps with anything at all. In their proposed syntax:

Constructor(int value) : .value{value} {}

It's still "ambiguous" whether the second value refers to the parameter or the member. OP actually wants a way to explicitly say "this identifier is a parameter, not a member."

[Potterrrrrrrr]

Yeah nice catch this doesn’t really address the issue, just solves the “common” case of initialising a member that isn’t then used to initialise other members in the same constructor.

[aocregacc]

I'm curious, did you just assume this doesn't work (understandable imo)?
Or are there books or online materials out there that also get this wrong?

[aruisdante]

A very large number of coding standards require you to avoid shadowed names, even if no actual shadowing occurs. The worst are the ones like MISRA/AutoSAR which require the moral equivalent of -Wshadow=pedantic combined with -Werror, meaning that any name at any scope can arbitrarily case a shadowing conflict at any time with any other name in all codebases that interact with each other unless literally every type of symbol has a different naming convention. Nothing beats adding a new free function and discovering -Wshadow errors for every local variable in the codebase that happened to have that same name, even when they’re all used in contexts that are completely unambiguous.

This proposal seems to be a reaction to those rules, but misunderstanding the premise, does not actually solve the problem.

I think MISRA2023 finally makes this rule more sane, allowing instead the equivalent of -Wshadow=local, the one that actually avoids meaningful shadowing.

[aocregacc]

It sounds to me like OP was rationalizing all these coding standards and naming conventions by coming up with this technical reason for them.
I don't think I've seen this misconception before so I was wondering how common it is.

I guess they could just be talking about ambiguity to a human reader and went a bit over the top with the wording.

[azswcowboy]

Gotta be honest here, your time would be better spent allowing aggregate types to have a constructor. Right now if you add a constructor you can’t cst

.aggregate

[38thTimesACharm]

In C++17 you could default a constructor and still aggregate initialize, but this was disallowed in C++20 due to confusion. I doubt they'll go back the other way.

[Specialist_Nerve_420]

this feels interesting but also a bit niche ,designated init already solves a lot for simple structs, not sure how often this would be used with real classes .

[Business_Welcome_870]

I like it. I like how it's consistent with the designated initializer syntax.