[202x][202y] Update proposals for correct targets #391
Conversation
This updates our current in-tree proposals for the correct language version targets. I've moved everything except proposal 0003, 0017 and 0022 into 202y since we almost certainly won't be taking any of those into 202x. I've also updated proposal 0020 with updated language around 202x and 202y reflecting my latest thinking. I've expanded the 202y documentation to discuss the major themes that are driving current likely 202y features and the associated breaking behavior changes.
proposals/0020-hlsl-202x-202y.md
Outdated
| docs](https://clang.llvm.org/docs/HLSL/ExpectedDifferences.html). Taking these | ||
| behavior changes into HLSL makes HLSL's overload best-match algorithm more | ||
| familiar and will produce ambiguous resolution errors instead of potentially | ||
| choosing the wrong overload when ambiguity exists in the source. |
There was a problem hiding this comment.
choosing the wrong overload when
I think "wrong" is kind-of subjective. Maybe "surprising" or "unexpected" or something about inconsistent choices?
proposals/0020-hlsl-202x-202y.md
Outdated
| Other C++ features have made their way in via Clang's implementation preserving | ||
| C++ constructs, but not all will be standardized in HLSL 202y. A few notable | ||
| features that should make the cut are: |
There was a problem hiding this comment.
I think there's some nuance here that might need expanding on for someone not immersed in thinking about language standards, What's the implication of a feature being available and seeming to work in Clang in 202y mode but not actually being standardized in 202y?
Or is the plan to disable these features that we don't manage to get standardized?
There was a problem hiding this comment.
I think most of them we'll disable outright. Some (like lambdas) we might test and find they work well enough that maybe we can just leave them in, although at that point we should probably decide what language version they're part of.
I'll work on the wording around this.
This updates our current in-tree proposals for the correct language version targets.
I've moved everything except proposal 0003, 0017 and 0022 into 202y since we almost certainly won't be taking any of those into 202x.
I've also updated proposal 0020 with updated language around 202x and 202y reflecting my latest thinking. I've expanded the 202y documentation to discuss the major themes that are driving current likely 202y features and the associated breaking behavior changes.