[swift-evolution] Infer types of default function parameters

[Daniel Leping]

I'm always positive with shorthand declarations, though this is a good
example of ambiguity pron case.

Signatures are signatures. Let's not mess with them.

On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hi all,
>
> I sent the message below to swift-users@ ~a day ago, but this might be a
> better place to ask and gather some discussion. It is a rather minor
> suggestion and I'm just looking for some opinions.
>
> Declaring a function that has default parameters currently looks like this:
>
> func foo(bar: String = "baz") {
>     print(bar)
> }
>
> Now I'm wondering if there would be any problems if it were possible to
> omit the type annotation for default params and let Swift's type inference
> handle that.
>
> func foo(bar = "baz") {
>     print(bar)
> }
>
> It feels to be equivalent to omitting type annotations with variable
> declarations. Obviously more complex types would still require annotations
> being specified. Off the top of my head I can't think of any negative
> ramifications this might bring, be it in simple function/method
> declarations or protocol extensions and elsewhere.
> Any further input or examples for situations where this might cause issues
> would be much appreciated :)
>
>
> I like the idea but I'm afraid I don't think I can support it.
>
> I think it is more important for function/method declarations to have as
> explicit a signature as possible; I mean, I'm not even that comfortable
> with the ability to omit -> Void on non-returning functions (I always
> include it just to be consistent).
>
> As others point out, while this makes sense for types where there's only
> one obvious choice to infer, it's not quite so clear on things like ints
> where a function really needs to be absolutely clear on what type/width of
> int it expects, since it's not something you want to have to change in
> future.
>
> One alternative I thought of was an operator for this purpose, e.g- :=
> (chosen since the colon kind of suits the omitted type declaration); this
> would allow a developer to be explicit about wanting Swift to infer the
> type, but it would be inconsistent with regular variables where it's always
> inferred, so I'm not sure if it'd be a good option anyway.
>
> Sorry, I do agree that it feels inconsistent that a function default
> doesn't behave more like a variable's initialisation, but at the same time
> they *are* two slightly different concepts so that's not necessarily a
> bad thing.
> _______________________________________________
> 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/20170311/9b486e7a/attachment.html>