[swift-evolution] Default Generic Arguments

[Srđan Rašić]

> If the answer to the above question is "yes, T is inferred as Int" then
we need some way to express "give me the default for T, which is Float."

I don't think that we need that. It would introduce a new level of
explicitness, "I want the default, but I don't care what the default is",
that is not really useful. If you don't care what the default type is, you
probably also don't care that you are defaulting. If you do care what the
default type is, you would explicitly sepecify it as `X<Float>`.


> If the answer to the above question is "no" then we need some way to
express "don't give me the default; rather, infer type T from the right
hand side."

That would be preferred behavior. Infer from the context if possible, use
default otherwise.


tir. 24. jan. 2017 kl. 05.11 skrev Xiaodi Wu <xiaodi.wu at gmail.com>:

> While it looks nicer without the angle brackets, that suggestion is
> unresponsive to David's point that we need some way to distinguish
> defaulted generic arguments from inferred generic arguments.
>
> Consider:
> ```
> let a: Optional = 1 // Optional<Int>
>
> enum FloatPreferringOptional<T = Float> {
>   case some(T)
>   case none
> }
>
> let b: FloatPreferringOptional = 1
> // Does this give you an FloatPreferringOptional<Int>?
> ```
>
> If the answer to the above question is "yes, T is inferred as Int" then we
> need some way to express "give me the default for T, which is Float." If
> the answer to the above question is "no" then we need some way to express
> "don't give me the default; rather, infer type T from the right hand side."
>
>
> On Mon, Jan 23, 2017 at 6:30 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This proposal looks good to me.  I have been looking forward to more
> flexible generic arguments for a while.
>
> I agree with previous commenters who prefer the option to leave off the
> angle brackets when all parameters have defaults.
>
> The proposal specifically mentions that the syntax is inspired by that of
> function arguments.  This is good, but I wonder if maybe we should draw
> further inspiration from function arguments and also add parameter labels
> for generic arguments.  Both feel like low hanging fruit in the generics
> area (correct me if I’m wrong about that) and it would be great to see both
> enhancements make it into Swift 4.
>
> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi Everyone,
>
> I've opened a PR (https://github.com/apple/swift-evolution/pull/591) proposing
> default generic arguments which I think would be nice addition to the
> language. They are also mentioned in "Generic manifesto".
>
> The proposal is focusing around generic types. Generic functions are not
> coved by the proposal and I don't think that we need default generic
> arguments in generic functions as all the types are always part of the
> function signature so the compiler can always infer them. One corner case
> might be if using default argument values in which case support for default
> generic arguments in functions might be useful.
>
> It would be great to hear your opinions and suggestions so I can refine
> the proposal.
>
>
> _______________________________________________
> 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/20170124/a647a47f/attachment.html>