[swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Howard Lovatt]

I tend to think an intended use annotation that could also be used in Obj-C
would be better than protected. The problem with protected is that it
provides virtually no protection at all; you can trivially expose it in a
derived class, e.g.:

class Protected {

protected func onlyDerived() { ... }

}

class Derived: Protected {

public override func onlyDerived() { super.onlyDerived() }

}

let d = Derived()
d.onlyDerived() // Protection lost

Therefore an annotation would be just as effective.

  -- Howard.

On 29 March 2016 at 21:54, Andrey Tarantsov via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > Imho it would be nice to be able to mark a method that is only there to
> be overridden and should never be called directly, but I don't think the
> compiler has to enforce this:
> > An official way to document the intent that affects autocompletion would
> be sufficient for me.
>
> An interesting idea that I see reflected in another proposal
> (intendedusage doc tag, or something like that).
>
> Why, though? If we can express it, why not also make it a part of the
> signature and get warnings/errors on violations?
>
> I have an argument in favor of annotations:
>
> + The documentation is known to lie and to get out of date, even when
> acting on best intentions. I know mine did, and I'm writing a lot less of
> it now. So I also see compiler-enforced annotations as “more reliable
> documentation”.
>
> What are other possible arguments for and against?
>
> > - callable (read for properties)
> > - can override, call to super enforced
> > - can override
> > - has to be overridden (abstract)
> > - properties only: Write access
>
> You're right, perhaps this isn't so much about access as it is about
> intended usage. (Not sure what that distinction means in practice, though.)
>
> A.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160330/e9892007/attachment.html>