[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa]

I don't disagree with you on 'fileprivate' and 'private' being
unnecessary and we may stick to the proposal at hand and leave the
'final' issue to another proposal, should anyone else care (I myself
don't mind if it sticks around - just have to not use it).

As for the conflict, I don't see it. Can you declare a 'public private
class'? I think it is just the same with 'open' and 'final'. And there
is no need to introduce an error for being redundant with 'public
final' either.

L

On 6 July 2016 at 18:36, Scott James Remnant <scott at netsplit.com> wrote:
>
> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
>
> You can also try and simplify your outlines reducing X.c and X.d to a
> single entry as it is the same rule applied to two different elements
> of the language. Using one single keyword (such as in 'open') would
> make it clearer and that is why I prefer to have only one keyword.
>
>
> I didn’t simply the outlines precisely because the proposal suggests two
> keywords.
>
> One keyword does solve this problem, but not the problem of conflation of
> finality and access control.
> You end up with this matrix:
>
>   access      | can override | final
>  -------------+--------------+-------
>   open        | yes          | Error - “class cannot be open and final"
>   public      | no           | Error - “public class is already final by
> default"
>   internal    | yes          | final
>   fileprivate | yes          | final
>   private     | yes          | final
>
> This is way more confusing than the current language:
>
>   access      | can override | final
>  -------------+--------------+-------
>   public      | yes          | final
>   internal    | yes          | final
>   fileprivate | yes          | final
>   private     | yes          | final
>
> I strongly favor a programming language that doesn’t introduce compiler
> errors to solve problems that could be solved by cleaner syntax.
>
> Since it’s already necessary to place the `public` keyword in front of every
> class, method, property, or subscript that you intend to make public, the
> developer is already thinking about the public API. Typing `public final`
> instead of `public` is an extra keyword, it’s not an extra cognitive burden
> since that cognition is already taking place.
>
> Scott
>