<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><span></span></div><div>Response inlined...<br><div class="AppleOriginalContents" style="direction: ltr;"><blockquote type="cite"><div>On Jan 24, 2016, at 03:08, Tino Heth <<a href="mailto:2th@gmx.de">2th@gmx.de</a>> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi David,</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="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; font-size: 11px; font-family: Menlo; margin: 0px; line-height: normal;"><span class="" style="color: rgb(187, 44, 162);">struct</span><span class="Apple-converted-space"> </span>BigInt <BaseType: T = <span class="" style="color: rgb(112, 61, 170);">Int</span>, CanEqualZero: U = <span class="" style="color: rgb(79, 129, 135);">Yes </span><span class="" style="color: rgb(187, 44, 162);">where</span><span class="Apple-converted-space"> </span>T: IntegerArithmeticType, U: BooleanType> {…}</div></div></blockquote></div>Is the "Yes" an error and it should be "True" instead?</div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;">Yep. I guess that’s what I get for changing my mind half-way through writing something :-)</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" 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).</blockquote>I don't think the rules have to be identical:</div><div class="">Methods are often verbs, so often, there is a natural "target" whose meaning can be inferred from the method name.</div><div class="">Generics are different — they "don't tell a story", and although there are situations where it seems one parameter is more relevant than the others ("BaseType" in you example), it would be odd to declare "BigIntWithBaseType<…".<blockquote type="cite" class=""><div class="" style="margin: 0px; line-height: normal;"></div></blockquote></div><div class="">I guess when there is a single parameter, its meaning is clear in most cases, but when you have more parameters, you cannot assume that the first should be treated different from the second (neither would it make sense to always treat them in the same way.</div><div class=""><br class=""></div><div class="">Every label useful:</div><div class="">let vector: Map<Index = UInt, Content = Double></div><div class=""><br class=""></div><div class="">No label useful:</div><div class="">class Comparer<L: BooleanType, R: BooleanType></div><div class=""><br class=""></div><div class="">It's to hard for the compiler to decide what should be done, and in such situations, my lazy solution is always "leave the decision to the user".</div></div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;">I guess I hadn't enough thought to the formal syntax. What I'd originally posted had a lot of colons by the time it was all typed out. Should we just copy the syntax from function arguments?<span style="background-color: rgba(255, 255, 255, 0);"> So the external label would default to being the same as the parameter name, unless you put a "_" in front of it or provided a different one? Seems like a waste to come up with two different syntaxes for two concepts that are so similar (plus, I think of generics as "compile-time arguments" anyway).</span></div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">Either way, I think parameters with default types would need to also have an external label, for the same reason that function arguments with default values can't externally be "_".</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">And, as Andrew suggested, anything with an explicit external label gets implicitly typealiased.</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I guess I'm to slow building my stupid litte proposal — but even if I haven't written an example for instantiation yet, I came to the same conclusion that labels can be useful for generics (<a href="https://github.com/SwiftTypesafeCalculations/Home/wiki/compile-time parameters" class="">https://github.com/SwiftTypesafeCalculations/Home/wiki/compile-time%20parameters</a>).</div><div class="">Your use case might benefit from it as well: affairs, "True" and "False" are only there to "lift" true and false into type-space, qualifying them as parameters.</div></div></div></blockquote><blockquote type="cite"><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Please feel free to comment or even co-author on "compile-time parameters" — I'm not sure I'll be bold enough to turn it into a real pull-request without external pressure ;-)</div><div class="">(afair, you already posted in the thread ["typesafe calculations"])</div><div class=""><br class=""></div><div class="">Tino</div></div></div></blockquote></div><div>Yeah, if that goes through (I really hope it does), those True/False types wouldn't be needed.</div></div></div><div><br></div><div>I'll take a closer look at your formal proposal as soon as I get a chance and let you know if I think I can contribute to it :-)</div><div><br></div><div>- Dave Sweeris</div></body></html>