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

[T.J. Usiyan]

+1

On Mon, Jan 25, 2016 at 2:44 PM, Dave via swift-evolution <
swift-evolution at swift.org> wrote:

> 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> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/187fd4a7/attachment.html>