[swift-evolution] [Further Discussion] Naming Attributes

[Shawn Erickson]

On Fri, Feb 19, 2016 at 1:05 PM Joe Groff via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Feb 19, 2016, at 12:17 PM, Erica Sadun <erica at ericasadun.com> wrote:
>
> *> Here's a problem*
>
> * There are Swift attributes: @autoclosure, @available, @objc, @noescape,
> @nonobjc, @noreturn, @testable, @warn-unused-result, @convention, @noreturn.
> * There are ObjC-ish/Xcode-ish attributes: @UIApplicationMain, @NSManaged,
> @NSCopying, @NSApplicationMain, @IBAction, @IBDesignable, @IBInspectable,
> @IBOutlet
> * There may be user-definable attributes under SE-0030: for example @lazy,
> @delayed; these are certainly attribute-ish, and it makes sense to present
> these using attribute-syntax.
> * The attribute syntax using `@` has had an intention "to open the space
> up to user attributes at some point"
>
> *> Namespacing*
>
> If Swift were to start accepting user-defined attributes,  it would need
> some way to differentiate and namespace potential conflicts. The most
> obvious solution looks like this:
>
> `@Swift.autoclosure`, `@UIKit.UIApplicationMain`, `@UIKit.IBOutlet`,
> `@Swift.noreturn`, `@Custom.lazy`, etc.
>
> Cumbersome, ugly, problematic.
>
> Once we open the floodgates for user-defined attributes, I think
> traditional namespacing and name lookup makes a lot of sense. We could
> conceptually namespace the existing hardcoded attributes into appropriate
> modules (Swift for the platform-neutral stuff, Foundation/AppKit/UIKit as
> appropriate for Appley stuff); name collisions would hopefully be rare
> enough that "@Swift.AutoClosure" or whatever hopefully won't often be
> necessary.
>

 Yeah I agree but I personally struggling with how it will play out.

For example given attributes are often only valid in narrow semantic
contexts. The compiler will enforce the semantics as needed of course and a
human reading the code would likely understand the attribute in the context
as written.

A human however may not easily understand the context in which a given
attribute could be used especially if user defined ones start popping up.
...so is a naming methodology used to help, e.g.
@Swift.PropertyBehaviour.lazy? or @MyStuff.PropertyBehaviour.extraLazy? ...
however this quickly become overly verbose and likely ill-defined in
naming, etc. Also it can duplicate what already can be understood from the
usage context.

Sorry handing waving about this nothing clear to add on a way forward. It
could imply contraction of problem domain to a more solvable one for a
first iteration or two on this unless things are better understood in
actually usage.

-Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160219/106f0b3b/attachment.html>