-1.
We already have a related feature for stored properties in structs and classes, and it causes a performance problem when compiling multi-file modules in non-WMO mode. Suppose you have:
— a.swift —
struct Box {
var x = <some very complex expression here with lots of overloads and generics>
}
— b.swift —
func takesABox(_: Box) {}
— c.swift —
func returnsABox() -> Box { return Box(x: …) }
When you run ‘swiftc a.swift b.swift c.swift’, we actually invoke the compiler three times:
swiftc -frontend -primary-file a.swift b.swift c.swift
swiftc -frontend a.swift -primary-file b.swift c.swift
swiftc -frontend a.swift b.swift -primary-file c.swift
In the first invocation, we’re emitting the declaration of ‘struct Box’ itself, so we have to type check its members, and infer the type of ‘x’. In the second invocation, we end up type checking takesABox(), which references the ‘Box’ type in its parameter list, so again we have to type check the members of ‘Box’ so that we know the ABI for ‘takesABox()’. And the third time, we’re type checking ‘returnsABox()’, which has ‘Box’ in its return type, so again, it has to be type checked so that we know its layout. This means the complex expression will be type checked a total of three times.
Now if you change a.swift to
struct Box {
var x: Int = <some very complex expression>
}
Then the expression only has to be type checked when compiling a.swift, so that we can emit the initializer for Box, but b.swift and c.swift immediately know the layout of Box without type checking the initializer (because the property type is declared explicitly).
If we allowed default argument types to be omitted, you would introduce the potential for similar compile time slowdowns. It would also create interesting circularity issues:
func foo(a = bar())
func bar(a = foo())
Here, you’d have recursion between the declaration checker and recursion checker when you go to type check either one of the two functions.
While neither of these challenges are insurmountable — we definitely plan on doing more to speed up the expression type checker, and circularity issues in declaration checking are also something we’ve been chipping away at in recent months — I would be against introducing any language features which make things worse in this regard.
Going back to the my original example here, Jordan Rose once suggested that stored properties inside types should always require a declared type — this might be too drastic for many people’s tastes, but I would definitely be in favor of that from an implementor's perspective ;-)
Slava
···
On Mar 10, 2017, at 1:40 PM, 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 :)
Cheers,
Kilian
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution