<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jun 24, 2016, at 6:04 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 22:20, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class="Apple-interchange-newline">Regards<div class="">LM</div><div class="">(From mobile)</div></div>On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md</a> ]</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">let callback: (Data) -> NSCoding & NSCopying</div></blockquote><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">However, I did remember one issue, which was brought up on the previous mega-thread: if we do want to <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials" class="">generalize protocol values</a>, 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 <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md" class="">SE-0081</a>.)</div><div class=""><br class=""></div><div class="">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.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This is another way to generalize P&Q compositions that opens another way to specify WHERE</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051" class="">https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051</a></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div></div></blockquote><br><div>Thank you for reading.</div><div><br></div><div>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"</div><div><br></div><div>Anyhow, it was an interesting mental exercise.</div><div><br></div></body></html>