<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 12:12 PM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">The “type parameter list” syntax is sugar that could be implemented as a layer on top of the current proposal or could be implemented orthogonally.<br class=""></blockquote>Hi Howard,<br class="">I've heard this argument before, so I'll repeat my answer as well:<br class="">Both offers don't make sense, it's either one way or the other (or something completely different).<br class=""></div></div></blockquote><div><br class=""></div><div>I don’t think it’s clear whether both make sense or not. They are not mutually exclusive and are aimed at solving related, but different problems. If we adopt the current proposal, the Kotlin / Scala syntax *might* make sense for some use cases. It would depend upon whether the current proposal is considered too verbose in enough cases or not. This may or may not turn out to be the case.</div><div><br class=""></div><div>The reason my proposal looks the way it does is because there are specific goals it intends to achieve and problems it is intended to solve. These goals and problems are not adequately addressed by the Kotlin / Scala syntax.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">If diversity starts here, why not have "const" and "val" beside "let", or allow "fn" and "lambda"?<br class=""><br class="">@Matthew: Please, if you support something, then say so - using clear words, not phrases like "could be implemented”.<br class=""></div></div></blockquote><br class=""></div><div>This phrasing is plenty clear IMO. I am stating a possibility. I do not have a position on whether or not it is a good idea at the moment.</div><div><br class=""></div><div>I have made some modifications to the proposal over the last few days. These changes have been partly motivated by considering the conversation we have had. You may wish to give it another look. If so, please look here: <a href="https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/0018-flexible-memberwise-initialization.md" class="">https://github.com/anandabits/swift-evolution/blob/flexible-memberwise-initialization/proposals/0018-flexible-memberwise-initialization.md</a>. There is currently an open PR for the latest change so it is not in the main Swift evolution repo yet.</div><div><br class=""></div><div>The most recent change includes a discussion of why it does not use the Scala / Kotlin syntax. You may not like the choice but I hope you can at least understand the rationale (even if you disagree with it).</div><div><br class=""></div><br class=""></body></html>