<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="">This is the 2nd time someone has pointed out that this, at least AFAICT, provides related functionality to parts of other proposals. It seems counterproductive to have multiple proposals out there with conflicting syntax for the same thing, especially when the different syntaxes could potentially have different corner-cases, which could be important to other parts of the proposal. Is there a “standard” way to make sure this isn’t stepping on anyone’s toes?<div class=""><br class=""></div><div class="">- Dave Sweeris<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 15:03, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><span class=""></span></div><div class=""><div class=""></div><div class="">In another thread:</div><div class=""><br class=""></div><div class="">[swift-evolution] Partially Constrained Protocols [Was:<span class="Apple-tab-span" style="white-space:pre">        </span>[Proposal] Separate protocols and interfaces]</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">This problem (and many others) could be solved with:</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; let foo = Foo&lt;where Self.U == Whatever&gt;(bar)</div><div class=""><br class=""></div><div class="">Where `T` is inferred to be of type `Int`.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">While this example is pretty verbose this kind of syntax can be used to use protocols with associated types as variables and generic covariant types.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">+1 for having label like behavior but they shouldn't be explicit since there could be confusion whether you declare a generic type or only a label. Therefore implicit typealiases (in this case `U` and `T`) should be used in conjunction with the approach above.</div><div class=""><br class=""></div><div class="">-1/+1 for default generic types because I imagine them to be useful in some (special) cases but I couldn't think of any useful real problem. So the additional syntax could not be worth its benefit.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Best regards</div><div class="">- Maximilian</div><div class=""><br class="">Am 25.01.2016 um 20:44 schrieb Dave via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">I’m not saying default values should be <i class="">required</i>, just that they be allowed if it makes sense. Plus, the way Array is defined, its generic parameter can always be inferred. In your example, `a` would be an array of IntergerLiteralType (which is currently typealiased to Int). However, it’s perfectly legal to define a struct for which the compiler can’t always infer all the generic parameters</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span> Foo &lt;T, U&gt; {</div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> value: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">T</span></div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">var</span> opt2ndValue: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">U</span>?</div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">init</span>(<span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">_</span> value: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">T</span>, opt2ndValue: <span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">U</span>? = <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">nil</span>) {</div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; &nbsp; &nbsp; <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">value</span> = value</div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; &nbsp; &nbsp; <span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">self</span>.<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">opt2ndValue</span> = opt2ndValue</div><div style="margin: 0px; line-height: normal;" class="">&nbsp; &nbsp; }</div><div style="margin: 0px; line-height: normal;" class="">}</div></div><div class="">In which case, the following code won’t compile:</div><div class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-family: Menlo; font-size: 11px; color: rgb(187, 44, 162);" class="">let</span><font face="Menlo" class=""><span style="font-size: 11px;" class=""> foo =&nbsp;</span></font><font face="Menlo" class=""><font color="#4f8187" class=""><span style="font-size: 11px;" class="">Foo</span></font><span style="font-size: 11px;" class="">(</span></font><span style="color: rgb(79, 129, 135); font-family: Menlo; font-size: 11px;" class="">bar</span><span style="font-size: 11px; font-family: Menlo;" class="">)</span></div></div><div class="">because <span style="color: rgb(112, 61, 170); font-family: Menlo; font-size: 11px;" class="">U</span>&nbsp;can’t be inferred. The current workaround:</div><div class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-family: Menlo; font-size: 11px; color: rgb(187, 44, 162);" class="">let</span><font face="Menlo" class=""><span style="font-size: 11px;" class="">&nbsp;foo =&nbsp;</span></font><font face="Menlo" class=""><span style="font-size: 11px;" class=""><font color="#4f8187" class="">Foo</font>&lt;Int, Whatever&gt;</span><span style="font-size: 11px;" class="">(</span></font><span style="color: rgb(79, 129, 135); font-family: Menlo; font-size: 11px;" class="">bar</span><span style="font-size: 11px; font-family: Menlo;" class="">)</span></div></div><div class="">requires you to specify <i class="">all</i> the types, which means that&nbsp;<span style="color: rgb(79, 129, 135); font-family: Menlo; font-size: 11px;" class="">bar</span>&nbsp;cannot be an inferred type, because this isn’t valid:</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(187, 44, 162);" class="">let<font face="Menlo" class="">&nbsp;foo =&nbsp;</font><font face="Menlo" class=""><font color="#4f8187" class="">Foo</font></font><span style="" class="">&lt;</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">bar</span><span style="" class="">.</span>dynamicType<span style="" class="">,&nbsp;</span><span style="" class="">Whatever</span><span style="" class="">&gt;(</span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">bar</span><span style="" class="">)</span></div></div><div class=""><br class=""></div><div class="">Default values for generic parameters let you maintain type inference, <i class="">if</i> it would make sense in your case. If it doesn’t, then don’t provide one.</div><div class=""><br class="webkit-block-placeholder"></div><div class="">
- Dave Sweeris

</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 01:00, Howard Lovatt &lt;<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">+1 for labels, I think generics are special arguments to `inits` and therefore labels make sense to me.</div><div class=""><br class=""></div><div class="">-1 for default values, the value is inferred if not specifically specified. What would:</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; let a = [1]</div><div class=""><br class=""></div><div class="">be? An `Int` array or an array of whatever the default generic type for an array is?<br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On 24 Jan 2016, at 7:38 AM, David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">The title seems fairly self-explanatory. Does anyone else think this could be useful?<div class=""><div style="margin: 0px; line-height: normal;" class=""><span style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 11px;" class="">struct</span><span style="font-family: Menlo; font-size: 11px;" class=""> True : </span><font color="#703daa" face="Menlo" class=""><span style="font-size: 11px;" class="">BooleanType</span></font><font face="Menlo" class=""><span style="font-size: 11px;" class=""> {…}&nbsp;</span></font><font color="#008400" face="Menlo" class=""><span style="font-size: 11px;" class="">// Just part of the example… n</span></font><span style="font-size: 11px; color: rgb(0, 132, 0); font-family: Menlo;" class="">ot in the proposal (although I do like it)</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="color: rgb(187, 44, 162); font-family: Menlo; font-size: 11px;" class="">struct</span><span style="font-family: Menlo; font-size: 11px;" class="">&nbsp;False : </span><font color="#703daa" face="Menlo" class=""><span style="font-size: 11px;" class="">BooleanType</span></font><font face="Menlo" class=""><span style="font-size: 11px;" class=""> {…} &nbsp;</span></font><font color="#008400" face="Menlo" class=""><span style="font-size: 11px;" class="">// Same</span></font></div></div><div style="margin: 0px; line-height: normal;" class=""><span style="color: rgb(0, 132, 0); font-family: Menlo; font-size: 11px;" class="">// This is where the actual idea starts</span></div><div class=""><div style="margin: 0px; line-height: normal;" class=""><div style="font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span> BigInt &lt;BaseType: T =&nbsp;<span style="color: rgb(112, 61, 170);" class="">Int</span>, CanEqualZero: U =&nbsp;<span style="color: rgb(79, 129, 135);" class="">Yes&nbsp;</span><span style="color: rgb(187, 44, 162);" class="">where</span> T: IntegerArithmeticType, U: BooleanType&gt; {…}</div><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">The first parameter label could be skipped (or not), depending on whatever the rules for functions parameter labels ends up being (either way, they should be the same IMHO). Then variables could be declared like this:</div><div style="margin: 0px; line-height: normal;" class=""><div style="font-family: Menlo; font-size: 11px; margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span> foo = &nbsp;&nbsp;<span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">BigInt</span>()<span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp;&nbsp;<span style="color: rgb(0, 132, 0);" class="">// BigInt&lt;Int, No&gt;()</span></div><div style="margin: 0px; line-height: normal;" class=""><div style="margin: 0px; line-height: normal;" class=""><font face="Menlo" style="font-size: 11px;" class=""><span style="color: rgb(187, 44, 162);" class="">let</span><font class="">&nbsp;bar = &nbsp;&nbsp;</font><span style="color: rgb(79, 129, 135);" class="">BigInt</span><font class="">&lt;Int32&gt;() </font><span style="color: rgb(0, 132, 0);" class="">// For when your data will be processed on a 32-bit platform or something</span></font></div></div></div><div class=""><div style="margin: 0px; line-height: normal;" class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-family: Menlo; font-size: 11px; color: rgb(187, 44, 162);" class="">let</span><font face="Menlo" class=""><span style="font-size: 11px;" class="">&nbsp;divisor&nbsp;=&nbsp;</span></font><span style="font-family: Menlo; font-size: 11px; color: rgb(79, 129, 135);" class="">BigInt</span><font face="Menlo" class=""><span style="font-size: 11px;" class="">&lt;CanEqualZero:&nbsp;</span></font><span style="color: rgb(79, 129, 135); font-family: Menlo; font-size: 11px;" class="">False</span><font face="Menlo" class=""><span style="font-size: 11px;" class="">&gt;()</span></font></div><div style="font-family: Menlo; font-size: 11px;" class=""><br class=""></div></div></div><div class="">(The obvious follow-up suggestion is to then allow a generic type’s definition to change based on the results of logical operations performed purely on the types that are passed in, but I think that’s getting into “macro system” territory, and should probably be its own thing.)</div><div class=""><br class=""></div><div class="">Anyway, thoughts?</div></div></div><br class=""><div class="">
- Dave Sweeris

</div>
<br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div></body></html>