> On Jun 24, 2016, at 6:04 PM, Jordan Rose <[email protected]> wrote: > > >> On Jun 23, 2016, at 22:20, L. Mihalkovic <[email protected]> >> wrote: >> >> >> Regards >> LM >> (From mobile) >> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution >> <[email protected]> wrote: >> >>> [Proposal: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md >>> ] >>> >>> I’ve gone on record before as against this syntax, although when I set out >>> earlier today to record my usual rebuttal I found that it really was mostly >>> a matter of taste. Yes, this looks weird to me: >>> >>> let callback: (Data) -> NSCoding & NSCopying >>> >>> but I’m sure the infix ‘->’ for functions looked weird to everyone the >>> first time they saw it as well, and it really is pretty clear in argument >>> position. >>> >>> However, I did remember one issue, which was brought up on the previous >>> mega-thread: if we do want to generalize protocol values, we’re going to >>> want something that’s essentially “a type with a ‘where’ clauses in it”. I >>> really don’t want to force people to use a typealias to spell such a type, >>> but at the same time I want that where clause to be clearly attached to the >>> type. (As brought up before the return position of a function is currently >>> ambiguous with SE-0081.) >>> >>> Despite the lightweightedness and the well-prepared proposal by Adrian and >>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance >>> against the proposed syntax. >> >> This is another way to generalize P&Q compositions that opens another way to >> specify WHERE >> >> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 > > Thanks for bringing this up. I know one reason we’ve avoided syntax like this > in the past is the potential for static subscripts, but of course that’s just > one of many future concerns. > > Jordan
Thank you for reading. Originally i wanted to make "[" and "]" be CONSTRAINT_BEGIN and CONSTRAINT_END respectively to signify that what mattered was the overall structure and how it degenerated into this syntax when the composition is not applied to a concrete type (i.e. naked P&Q), as well as show that this gave a formal definition to Any: a zero term composition that is not limited to a single concrete type, otherwise spelled "_ CONSTRAINT_BEGIN CONSTRAINT_END" Anyhow, it was an interesting mental exercise.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
