> > This work is based on the previous discussion thread on this list of the > same name, and hopefully captured all the relevant details, > notwithstanding anything unanticipated that may present itself during > the implementation. Let me know if you feel anything important has been > missed. I am aware it omits to mention specifics about messages so > emitted when runtime or compile-time errors occur, but I anticipate this > can be hashed out in the PR, unless consensus indicates otherwise.
Hi Bilge, I was reading the mailing list discussions, and I am glad you created the RFC. Personally, I think this will be a useful feature. Just like we have `readonly` properties and `readonly` classes, I don't see why we can't have static methods. I also saw in the draft PR that it does not require a lot of changes to the engine to have this. I'd like to propose to add some more information and points addressed in the RFC. This is of course merely a suggestion, but it's something I was thinking when reading the RFC. - Why is it a class-level flag and not an attribute (similar to the `#[Override]` attribute in PHP 8.3) ? - Can a subclass extend a static parent class without using the `static` keyword in the subclass? This will avoid a lot of BC issues if a library decides to declare classes as static. - Are there any opt-out mechanisms for subclasses? - Can you mark interfaces, abstract classes, and Enums as static?
