[swift-evolution] Idea: Let Generic Parameters Have Labels & Default Values

[davesweeris at mac.com]

I’m not saying default values should be required, 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
struct Foo <T, U> {
    var value: T
    var opt2ndValue: U?
    init(_ value: T, opt2ndValue: U? = nil) {
        self.value = value
        self.opt2ndValue = opt2ndValue
    }
}
In which case, the following code won’t compile:
let foo = Foo(bar)
because U can’t be inferred. The current workaround:
let foo = Foo<Int, Whatever>(bar)
requires you to specify all the types, which means that bar cannot be an inferred type, because this isn’t valid:
let foo = Foo<bar.dynamicType, Whatever>(bar)

Default values for generic parameters let you maintain type inference, if it would make sense in your case. If it doesn’t, then don’t provide one.

- Dave Sweeris

> On Jan 25, 2016, at 01:00, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> +1 for labels, I think generics are special arguments to `inits` and therefore labels make sense to me.
> 
> -1 for default values, the value is inferred if not specifically specified. What would:
> 
>     let a = [1]
> 
> be? An `Int` array or an array of whatever the default generic type for an array is?
> 
> Sent from my iPad
> 
> On 24 Jan 2016, at 7:38 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> The title seems fairly self-explanatory. Does anyone else think this could be useful?
>> struct True : BooleanType {…} // Just part of the example… not in the proposal (although I do like it)
>> struct False : BooleanType {…}  // Same
>> // This is where the actual idea starts
>> struct BigInt <BaseType: T = Int, CanEqualZero: U = Yes where T: IntegerArithmeticType, U: BooleanType> {…}
>> 
>> 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:
>> let foo =   BigInt()	    // BigInt<Int, No>()
>> let bar =   BigInt<Int32>() // For when your data will be processed on a 32-bit platform or something
>> let divisor = BigInt<CanEqualZero: False>()
>> 
>> (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.)
>> 
>> Anyway, thoughts?
>> 
>> - Dave Sweeris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/bf930e49/attachment.html>