[SUGGESTION] Can we combine inheritance and duck type and get something better?

[YagaoDirac]

I know people already talked about such ideas a lot. Here's my version.
No quantization result, since I'm not pro researcher in this area.
I'm not suggesting any syntax. This idea works with any syntax.

Inheritance is good because you write very little and get a decent starting point for a new class.

Duck type is good because you have abs control of a class, so you can make containers more precisely, and never pay for what you don't need.

Inheritance is bad because when you have to remove a lot funcs or vars, it's pain. And in c++, inheritance has a different syntax than other parts(the ":public some_class" part)
Duck type is bad because when you have to add a lot funcs or vars, it's pain.

The idea is pretty similar to what we saw in the latest 2023 cppcon video.
class A{int A;}
class AB{int B;}
compilercommand.class("AB").add_all_members_from("A");
class AC{int C;}
compilercommand.class("AC").add_all_members_from("A");
class ABC{}
compilercommand.class("ABC").add_all_members_from("AB").add_all_members_from("AC").remove_duplicated_members();
The result is like:
A: int A
AB: int A,B;
AC: int A,C;
ABC: int A,B,C;
If all the classes are super big with hundreds of vars and funcs, this idea allows you to add or remove anything for any class. The control is very precise. This can also help when people need to provide a whole set of callbacks, while inheritance doesn't help.
The advantage is, "compiler command"shares the same syntax with other parts, and the dot operator triggers auto completion which eliminates guess work.
Also, we can do this to functions.
void function1(){}
compilercommand.func("function1").set_no_throw().set_const();

Maybe we can also do:
if some condition{
compilercommand.if.set_likely();
}else
{
//if you call compilercommand.if.set_likely(); again here, it's a compiler error.
}

Maybe also this:
int*** pppi;
compilercommand.var("pppi").set_const(2).set_const(0);
//I mean, const int**const* pppi;

If all the compiler commands start with "compilercommand.", people don't have to guess if something is a compiler command, and the dot always triggers auto completion, so people don't have to remember the first 5 char of each command, and they can browse all the command available without opening a docs website. And it's easy for people to google. In docs website, people can expect to browse all the commands, without concerning missing anyone. If they start with their own names, maybe only the official docs page provide the entire list, if someone hates to go to the official doc page for some reason I don't know or care, it's unlikely to learn the new features systematically.

Instruction like syntax has 1 more advantage over flag like syntax is that, you can debug(single step) it, and maybe we can have a print function so people can clearly know what is happening. And maybe we can "go to definition" with compiler command. I don't know how to add a "go to definition" for flag like syntax in a reasonable way.

Such compiler commands also may help with backward compatibility.
If some feature is modified and some "by default" behavior is modified, we can add a specific compiler command to the line, so the behavior is maintained, but the default behavior of the language itself is modified(because of version changes). I'm not sure, this trick may help partly.

Btw, a similar idea, the feature space, which is similar to namespace but it's for features. I don't believe mixing cpp2 code and cpp1 code is a good idea. If you are going to do it, maybe some scope controlling is useful. Feature scope may also help with version problem.

I don't have other ideas for this problem now. I think this one is a relatively general way.

[AbhinavK00]

Some feedback:

1. This feature allows the programmer to modify already defined entities which I don't think should be allowed. Solution to this: Move the uses to inside the class, so the feature can only be used when declaring the class.
2. This makes sense for classes, but for functions and variable? I think not. Just declare the variable/function as it is.
3. For the .if.set_likely feature, fpp already has attributes [[likely]] and [[unlikely]].
4. I think this may have some overlap with [SUGGESTION] Composition in cpp2 with metafunctions #750