> On Feb 17, 2017, at 10:55 AM, David Sweeris <daveswee...@mac.com> wrote: > > > On Feb 17, 2017, at 08:49, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> >>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
