> On Mar 14, 2017, at 9:40 PM, Slava Pestov via swift-evolution
> <[email protected]> wrote:
>
> -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())
>
To be fair, the compiler is currently able to handle a similar situation:
struct Foo {
static let foo = Bar.bar
}
struct Bar {
static let bar = Foo.foo
}
error: 'foo' used within its own type
static let foo = Bar.bar
^
error: could not infer type for 'foo'
static let foo = Bar.bar
^
I definitely understand wanting to reduce inference along these boundaries, but
type inference for struct members can be extremely useful.
> 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
>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
