<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="">Am 11.01.2016 um 18:17 schrieb Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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="">These proposals are partly a response to the comments Dave and Joe made about building on more general underlying features.</div><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I am afraid they are not general enough for my taste and leaning too much towards initialization.</div><div class=""><br class=""></div><div class=""><div class=""><b class="">Parameter forwarding:</b></div><div class="">This does not make the language more expressive, i.e. there is no abstraction of the parameter list. I cannot do anything with it except forwarding it. That seems not very useful, it just allows saving some keystrokes which is not really necessary.</div><div class=""><br class=""></div><div class="">Furthermore the syntax is really wrong in my opinion:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// user writes:</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">bar</span>(<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span>fooParams) {
foo(i: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">32</span>, <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span>fooParams)
}</pre><div class=""><br class=""></div><div class="">The problem is that I do not see anymore what the API of bar() is! I have to look at method foo() (after scanning the body of bar() to find it) and look there. That’s really bad.</div><div class=""><br class=""></div><div class="">Something like the following (just using some random syntax) would be much better, as it (1) keeps the API of bar() visible and (2) abstracts over the arguments giving us a handle to manipulate it.</div><div class=""><br class=""></div><div class="">func bar(i i: Int, s: String, f: Float = 42, d: Double = 43, b: Bool = false) {<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>foo(#arguments.with(i: 32))</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// we can do something with #arguments!</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for (Argument arg in #arguments) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print("\(arg.name): \(arg.type) = \(arg.value)“)</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div></div><div class=""><br class=""></div><div class="">But then I’m not sure what concrete problems this would solve. Writing out the parameter list is not so bad. I’d wager that in cases of long argument lists a redesign would be better, i.e. by encapsulating groups of parameters into structs or classes (which will probably attract behavior as well in contrast to the property list tuples).</div><div class="">I’d really like to see some concrete examples of use cases where this would be useful and better than refactoring the design.</div></div><div class=""><br class=""></div><div class=""><b class="">Partial initializers:</b></div><div class="">These might have the most merit but are a special case of initialization, so there is nothing gained in general expressivity.</div><div class=""><br class=""></div><div class=""><b class="">Property Lists:</b></div><div class="">This is an attempt to solve the problem of the „members“ attribute having to be narrowed for different use cases, like narrowing with regards to var parameters only or with regards to accessibility. Declaring the different views which are required for a specific class or struct explicitly as property list is an interesting solution for that and might possibly be the right thing for a statically safe language. </div></div><div class="">What I definitely don’t like is having a partial initializer automatically being created as well. I’m not too fond of automatically created code as that is (a) not visible, (b) therefore not part of the documentation (and even if the documentation gets enriched by explicit entries for automagic functions, which would be nice [the memberwise initializer should be auto-expanded in the documentation, for example], it is still not visible in the source file), and last not least it is (c) not searchable.</div><div class="">Currently I’m thinking the potential problems to be solved with this are not worth the magic (= making the language more difficult and reducing the readability of code).</div><div class=""><br class=""></div><div class="">-Thorsten</div></body></html>