On Fri, May 17, 2024, at 3:49 PM, Tim Düsterhus wrote: > Hi > > On 5/17/24 17:02, Larry Garfield wrote: >> Why is the attribute not allowed on classes? I think it would make sense on >> every language structure, unrestricted. (Including classes, parameters, >> everything.) > > There is not pre-existing semantics of deprecating a class from the > engine PoV. > > The only things that can be deprecated on the engine level as of now are > Functions, Methods, Class Constants (incl. Enum Cases), and regular > Constants (those do not support attributes). > > Allowing to apply the attribute on classes is therefore left to future > scope (as mentioned in the “Future Scope” section of the RFC). Adjusting > the attribute to also apply to classes once the semantics are decided > should be straight-forward and thus be an implicit part of the process > of supporting the deprecation of classes.
This would be helpful to include explicitly in the RFC, toward the top, because it's the first thing that came to mind when I saw the initial code block. >> The user-space definition of the attribute is invalid in the example: It >> declares properties AND promoted constructor args. That can/should be >> combined. > > I don’t follow. Do you mean the top-most codeblock in the RFC? It does > not use constructor property promotion. > > It’s the stub, intentionally omitting the method body. I’ve added a > placeholder comment in the constructor body to make that clearer. Ah, I misread it. You are correct, it's valid. It's so rare I see a name in both the constructor and as a property these days. :-) --Larry Garfield
