The decision on the mailing list was that just as internal types can have
either internal or private members, an extension implicitly marked 'internal'
can have either internal or private members, but no public members. This
occurs when an extension is given an explicit accessibility that is less
than the type's accessibility.
Swift SVN r20226
There's no meaningful way in which these methods are public, since they
can't be accessed through any value of the type
<rdar://problem/17647878>
Swift SVN r20224
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
...unless they are in a private class.
Consider this scenario:
class Base {
func foo() -> Base { ... }
}
class Sub : Base {
private override func foo() -> Sub { ... }
}
class Grandchild : Sub {
override func foo() -> Base { ... }
}
Because Grandchild can't see Sub, its override of foo() looks perfectly
reasonable...but now Sub's expectations for foo() have been broken.
Swift SVN r19769
...because you can't match them properly in switches.
In the future, we could consider allowing private enum cases in a
resilient public enum, which essentially forces the user to consider the
default case.
Swift SVN r19620
In theory there's nothing wrong with this, but it makes it hard to see what
operations a class supports, and there's no obvious way to go to its nearest
public superclass.
Note that we have a similar issue with protocols, since private protocols can
refine public protocols, and then public classes can conform to private
protocols---the indirect conformance won't be listed in the inheritance
clause, but it is a public conformance nonetheless.
Swift SVN r19588
While this could be useful, a raw type implies a conformance to
RawRepresentable, and private methods cannot be used to satisfy conformances
of public types to public protocols.
Swift SVN r19587
Also, don't diagnose accessibility violations on implicit decls. Every now
and then the compiler needs to bend the rules, such as when providing an ==
implementation for a local enum.
Swift SVN r19519
We could actually allow the default definition of an associated type to have
less accessibility than the requirement, but then we'd also have to check
that that type wasn't being used where it wasn't accessible. Since we infer
associated types anyway, it's probably not worth it.
Swift SVN r19493
This does not yet handle variables with inferred types, since those don't
have TypePatterns.
There is some nasty propagation of @public into the stdlib because of this
one, mainly because Foundation needs access to some of the implementation
details of Array and Dictionary. We may want to try to improve this later
(or just build Foundation with -disable-access-control if it comes to that).
Swift SVN r19432
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
