<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=""><div>Hi David,</div><div><br class=""></div><div><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 class=""><br class=""></div><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"><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 class=""><br class=""></div><div>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>Your use case might benefit from it as well: afaics, "True" and "False" are only there to "lift" true and false into type-space, qualifying them as parameters.</div><div><br class=""></div><div>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>(afair, you already posted in the thread ["typesafe calculations"])</div><div><br class=""></div><div class="">Tino</div></body></html>