[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Matthew Johnson]

> On Feb 17, 2017, at 10:55 AM, David Sweeris <davesweeris at mac.com> wrote:
> 
> 
> On Feb 17, 2017, at 08:49, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> 
>>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> I haven’t yet read all the feedback in this topic but I’d like to throw some bikeshedding of mine into the room. :)
>>>> 
>>>> How about this?
>>>> 
>>>> Version 1: func(pure) …
>>>> Version 2: func label(…) ~> ReturnType
>>> Version 2 is going to upset those who use "~>" as an operator.
>>> 
>>> As the # of possible attributes grows, having an obvious grouping mechanism for them, like version 1, might be worthwhile simply to help make the list clearer. What about allowing "@(list, of, attributes)" instead of "@list, @of, @attributes”?
>> 
>> That would be a little bit awkward for attributes that are parameterized.
> 
> Are there any parameterized attributes other than "@inline(always|never)”?

I am not sure, but there has been discussion of introducing them.  For example, regardless of what syntax we choose for indicating a public enum is closed it will need to have an optional parameter indicating the first version of the library in which it was closed (which can be omitted if it was closed the first time it appeared).  One option for indicating this is to use an attribute.

> 
>> And if we did do this we should allow the parens to be omitted when there is only one attribute.
> 
> Agreed.
> 
> - Dave Sweeris 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/e9960299/attachment.html>