[swift-evolution] [Discussion] Replacing Equal Signs with Colons For Attribute Arguments

Erica Sadun erica at ericasadun.com
Tue Feb 16 21:32:53 CST 2016 

That's beyond the scope of this proposal. If you want to discuss it, I encourage you to start a separate thread.

-- E


> On Feb 16, 2016, at 7:54 PM, Michael Wells <michael at michaelwells.com> wrote:
> 
> Aren’t we removing the use of snake case in Swift 3? So should @warn_unused_result be de-snake-cased?
> 
>> On Feb 16, 2016, at 6:45 PM, Ricardo Parada via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> It looks very good.  
>> 
>> Thank you Erica.
>> 
>> 
>>> On Feb 16, 2016, at 8:05 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>> 
>>> Adding:
>>> 
>>> @available(*, unavailable, renamed: "MyRenamedProtocol")
>>> typealias MyProtocol = MyRenamedProtocol
>>> 
>>> @warn_unused_result(mutable_variant: "sortInPlace")
>>> public func sort() -> [Self.Generator.Element]
>>> 
>>> @available(*, deprecated, message: "it will be removed in Swift 3.  Use the 'generate()' method on the collection.")
>>> public init(_ bounds: Range<Element>)
>>> 
>>> gist: https://gist.github.com/erica/d96011a5c22d9b995b91 <https://gist.github.com/erica/d96011a5c22d9b995b91>
>>> 
>>> -- E
>>> 
>>>> On Feb 16, 2016, at 5:43 PM, Charles Kissinger <crk at akkyra.com <mailto:crk at akkyra.com>> wrote:
>>>> 
>>>> 
>>>>> On Feb 16, 2016, at 4:08 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Ricardo,
>>>>> 
>>>>> This proposal is so narrow that I believe *every single example possible* is already in there under motivation. Just sub out each "=" for ":" and you have the entire extent of the change.
>>>> 
>>>> Hi Erica,
>>>> 
>>>> I think Ricardo means full examples of the new style, including @ symbol, attribute-name, parens, attribute argument label and example attribute arguments. There are no full examples in the proposal of either the existing or proposed style.
>>>> 
>>>> It might seem nit-picky (and it is :-)), but that’s the only way for us to evaluate how it will actually look in practice. (Yes, we could look up a few and type them in somewhere ourselves, but it would be nice to have them in the proposal.)
>>>> 
>>>> —CK
>>>>  
>>>>> 
>>>>> -- Erica
>>>>> 
>>>>>> On Feb 16, 2016, at 5:03 PM, Ricardo Parada <rparada at mac.com <mailto:rparada at mac.com>> wrote:
>>>>>> 
>>>>>> Hi Erica,
>>>>>> 
>>>>>> I understand this is a draft and even though it may be obvious to many, I would add a few examples with the proposed solution.
>>>>>> 
>>>>>> Thanks
>>>>>> Ricardo Parada
>>>>>> 
>>>>>> 
>>>>>>> On Feb 16, 2016, at 5:42 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> 
>>>>>>> Thoughts and feedback appreciated. Thank you, -- Erica
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Replacing Equal Signs with Colons For Attribute Arguments
>>>>>>> 
>>>>>>> Proposal: TBD
>>>>>>> Author(s): Erica Sadun <http://github.com/erica>
>>>>>>> Status: TBD
>>>>>>> Review manager: TBD
>>>>>>>  <https://gist.github.com/erica/d96011a5c22d9b995b91#introduction>Introduction
>>>>>>> 
>>>>>>> Attribute arguments are unlike other Swift language arguments. At the call site, they use = instead of colons to distinguish argument names from passed values. This proposal brings attributes into compliance with Swift standard practices by replacing the use of "=" with ":" in this one-off case.
>>>>>>> 
>>>>>>> Discussion took place on the Swift Evolution mailing list in the [Discussion] Replacing Equal Signs with Colons For Attribute Arguments thread. Thanks to Doug Gregor <https://github.com/DougGregor> for suggesting this enhancement.
>>>>>>> 
>>>>>>>  <https://gist.github.com/erica/d96011a5c22d9b995b91#motivation>Motivation
>>>>>>> 
>>>>>>> Attributes enable developers to annotate declarations and types with keywords that constrain behavior. Recognizable by their at-sign <http://foldoc.org/strudel> "@" prefix, attributes communicate features, characteristics, restrictions, and expectations of types and declarations to the Swift compiler. Common attributes include @noescape for parameters that cannot outlive the lifetime of a call, @convention, to indicates whether a type's calling conventions follows a Swift, C, or (Objective-C) block model, and @available to enumerate a declaration's compatibility with platform and OS versions. Swift currently offers about a dozen distinct attributes, and is likely to expand this vocabulary in future language updates.
>>>>>>> 
>>>>>>> Some attributes accept arguments: @attribute-name(attribute-arguments) including @available and @warn_unused_result. In the current grammar, an equal sign separates attribute argument keywords from values:
>>>>>>> 
>>>>>>> introduced=version-number
>>>>>>> deprecated=version-number
>>>>>>> obsoleted=version-number
>>>>>>> message=message
>>>>>>> renamed=new-name
>>>>>>> mutable_variant=method-name
>>>>>>> Using = is out of step with other Swift parameterization call-site patterns. Tweaking the grammar to match the rest of Swift introduces a small change that adds consistency across the language.
>>>>>>> 
>>>>>>> parameter name: parameter value
>>>>>>>  <https://gist.github.com/erica/d96011a5c22d9b995b91#detail-design>Detail Design
>>>>>>> 
>>>>>>> This proposal replaces the use of = with : in the balanced tokens used to compose an attribute argument clause along the following lines:
>>>>>>> 
>>>>>>> attribute → @ attribute-name attribute-argument-clause<sub>opt</sub>
>>>>>>> attribute-name → identifier
>>>>>>> attribute-argument-clause → ( balanced-tokens<sub>opt<opt> )
>>>>>>> balanced-tokens → balanced-token
>>>>>>> balanced-tokens → balanced-token, balanced-tokens
>>>>>>> balanced-token → attribute-argument-label : attribute argument-value
>>>>>>> This design can be summarized as "wherever current Swift attributes use =, use : instead".
>>>>>>> 
>>>>>>>  <https://gist.github.com/erica/d96011a5c22d9b995b91#alternatives-considered>Alternatives Considered
>>>>>>> 
>>>>>>> There are no alternatives to put forth other than not accepting this proposal.
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160216/da44f924/attachment.html>

More information about the swift-evolution mailing list