+1
I like that python style shorthand.
On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution <
swift-evolution@swift.org> wrote:
> 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@swift.org> wrote:
>
>
> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution <
> swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
