Hello Saif sob., 24 kwi 2021, 13:00 użytkownik Saif Eddin Gmati <azj...@protonmail.com> napisał:
> A major behavior i wanted to discuss is how should sealed interfaces work, > and specially around `Throwable` which is currently sealed to only `Error` > and `Exception`, but allows other interfaces to extend it, and other > classes to implement it as long as they extend `Error` or `Exception` ( or > another class that does so ). > > As per the current proposal, if `Throwable` is to be declared `sealed`, > permitting only `Error` and `Exception`, it won't be possible to extend it, > resulting in a major BC-break, considering that too many libraries extend > this interface in their own `ExceptionInterface`. > > To work around this, there's two solution: > > 1. don't declare `Throwable` sealed and keep it as a special case. > 2. interfaces declared sealed, can be extended by other interfaces, > however, classes that implement either the sealed interface directly, or > via another interface, have to extend one of the classes the sealed > interface permits. > > The second solution will allow declaring `Throwable` sealed, and would > bring complete consistency between internally sealed symbols, and user > land, without any BC breaks, and IMHO, it doesn't hurt as at the end, no > one will be able to implement `Throwable` without extending the permitted > classes. > I like the idea of sealed class along with proposed keywords which are similar to already existing in other languages like Java. Personally I'd go with the second option. Speaking of Attributes I prefer not to use an Attribute for any particular language feature which expects input arguments to be a valid class or interface name for two reasons: first because there is no effective way to restrict input string to be a valid class or interface name and second that it'd require passing strings which means in most cases passing class or interface name with magic ::class constant read. Cheers, Michał Marcin Brzuchalski
