Perfect forwarding

[Petar]

On Monday, 27 July 2020 at 21:08:52 UTC, Andrei Alexandrescu 
wrote:
> [..]
>
> Thanks for asking. I'm no longer in the decision loop but 
> here's what I think. There'd be somewhat obvious traits to have 
> ("is this symbol deprecated?") and traits that work together 
> toward a larger goal, such as perfect forwarding or general 
> introspection itself. In the former case acceptance could and 
> should be somewhat quick, whereas in the latter case we risk 
> having a hodge-podge of traits that don't combine properly to 
> attain the initial goal. In a way we're there right now - we 
> added traits on a need basis and we're unclear on what the 
> limits of what we can and what we can't do, or how to do it.

So the question is what do we do about the new traits proposed by 
[1]? How formal does the process needs to be about them? I see 3 
options:
1. Traits or otherwise any language features part of a larger 
story (e.g. template parameter introspection, perfect forwarding) 
need to go through a 2 step DIP process:
   1) A strategic/vision DIP that states the high-level problem 
that we want to solve. The goal of this DIP would be form 
community and leadership consensus on whether something is a 
strategic goal for D and whether we need to solve it.
   2) A tactical DIP that proposes concrete language features and 
defines their semantics. In this case these would be the traits 
proposed by [1].

2. The language maintainers (Atila and Walter) decide on each DMD 
PR on a case-by-case basis.

3. New traits that haven't gone through a DIP process are 
considered experimental and can be added behind a compiler switch 
(which either enables all experimental traits, or each one 
individually). Such traits continue to have experimental status 
for several releases until we gather real-world experience and we 
decide to either remove, change, or to stabilize them (make them 
generally part of the language and available without any switch).
Unlike 2. any dmd contributor (or perhaps a group of minimum of 
2/3 people?) with write access to the dmd repo can decide to 
merge such experimental traits, after some minimal requirements 
are met, such as a changelog entry and sufficiently thorough 
test(s) that demonstrate the usefulness of the feature and cover 
all knownedge edge cases (e.g. each added error message is 
tested).

@Andrei @Atila @Walter what do you guys think?

[1]: https://github.com/dlang/dmd/pull/5201