yes, exactly Doug... the properties at type level are part of the interface and
their types can be inferred, so i don't see the difference with function
argument types.
i just find it really bulky when writing something like this:
func doSomething(thing, withManager: SomethingManager = SomethingManager()) {
// prepare the thing
}
I think this meets the API guidelines for "omitting needless words"
And it should be invalid syntax to expect the type to be inferred for a generic
argument (i.e. no change from current behaviour)
> On 11 May 2016, at 04:53, Douglas Gregor <[email protected]> wrote:
>
>
>
> Sent from my iPhone
>
>> On May 10, 2016, at 8:33 PM, Chris Lattner via swift-evolution
>> <[email protected]> wrote:
>>
>>> On May 10, 2016, at 3:02 AM, Sam Dods via swift-evolution
>>> <[email protected]> wrote:
>>> I propose that function argument types could be omitted in the same way as
>>> variable and property argument types are omitted when they are set at point
>>> of definition.
>>>
>>> At present the type of properties and variables can be inferred as below:
>>>
>>> class EvolutionManager {
>>> let proposalManager = ProposalManager() // type is inferred
>>>
>>> func proposeTopic(topic: String) {
>>> let evolution = Evolution(topic: topic) // type is inferred
>>> proposalManager.proposeEvolution(evolution)
>>> }
>>> }
>>>
>>> However, function arguments cannot be inferred, as below:
>>>
>>> class EvolutionManager {
>>> func proposeEvolution(evolution: Evolution, proposalManager =
>>> ProposalManager()) { // compiler error, cannot infer type
>>
>> We have a pretty strict rule here: types are allowed to be inferred in
>> implementations, but not interfaces. This is important for efficient
>> compilation, encourages people to think about their API interfaces, and
>> somewhat reduces the damage when they don’t.
>
> We broke this rule when we started allowing properties at type and module
> scope to have inferred types. I was moderately opposed to it at the time, but
> we have it, we're going to keep it, and this suggestion for inferring
> parameter types from default arguments seems to fit in the same category.
>
> That said, I have implementation concerns: we don't want the expression type
> checker to be involved when figuring out the type of a generic function, so
> we would need to define this in a way that doesn't affect the computation of
> generic signatures for a function. Probably, such types just aren't involved
> in inferring generic constraints.
>
> - Doug
>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
