[swift-evolution] Partial list of open Swift 3 design topics
Vladimir.S
svabox at gmail.com
Tue Jun 28 12:30:56 CDT 2016
On 28.06.2016 19:49, Austin Zheng via swift-evolution wrote:
> This makes sense. If nobody objects I'll prepare a proposal today.
Austin, I'd ask to review this related(about function/closure type) thread
in mailing list before preparing the proposal: "[Proposal] Disallow
implicit conversion between function/closure with a list of parameters and
with tuple parameter. Remove function type inconsistency."
I mean probably you'll want to form a more generic proposal to improve/make
less surprising Swift's function types and add consistency in this area.
I'd be happy if you'll add ideas from the thread mentioned above to your
proposal.
>
> By the way, on the topic of design topics: is there any core team
> support for removing associated type inference? I have a proposal there
> that I would like to move into the formal review stage at some point.
>
> Best, Austin
>
> Sent from my iPhone
>
>> On Jun 28, 2016, at 9:33 AM, Douglas Gregor <dgregor at apple.com>
>> wrote:
>>
>>
>>> On Jun 27, 2016, at 10:40 PM, Charlie Monroe
>>> <charlie at charliemonroe.net> wrote:
>>>
>>> Oh, I see. The issue is then the following:
>>>
>>> let x = f x(1, 2) // Error: Missing argument labels 'a:b:' in call
>>>
>>> let y: (Int, Int) -> () = f f(1, 2) // OK
>>>
>>> Which requires you to write x(a: 1, b: 2). I must admit, however,
>>> that I always liked this behavior…
>>
>> Right, that’s the issue. The idea behind this is that it’s a
>> simplification to the type system to eliminate argument labels from
>> types, so we can eliminate some extra subtyping relationships (e.g.,
>> between function types with labels and ones without labels).
>> Essentially, argument labels become part of the names of declarations
>> (only!), which is consistent with our view that the names of
>> functions/methods/initializers include all of the argument names.
>>
>> - Doug
>>
>>>
>>>> On Jun 28, 2016, at 7:06 AM, Austin Zheng <austinzheng at gmail.com>
>>>> wrote:
>>>>
>>>> I think the point is to get rid of the argument labels. 'x' should
>>>> be typed simply (Int, Int) -> ().
>>>>
>>>> That being said, right now the argument labels in the type don't
>>>> seem to actually affect anything, so like Chris I'm not sure what
>>>> the counter-proposal is.
>>>>
>>>> (cc. Doug)
>>>>
>>>> Best, Austin
>>>>
>>>>>> On Jun 27, 2016, at 10:04 PM, Charlie Monroe
>>>>>> <charlie at charliemonroe.net> wrote:
>>>>>>
>>>>>> This came from a short list of topics Doug provided me, but
>>>>>> the basic issue is that:
>>>>>>
>>>>>> func f(a : Int, b : Int) { let x = f // x has type (a: Int,
>>>>>> b: Int) -> () }
>>>>>>
>>>>>> I’m not exactly sure what the counterproposal is.
>>>>>
>>>>> My guess is to require let x = f(a:,b:) (specifying arguments)?
>>>>>
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>
>>
> _______________________________________________ swift-evolution mailing
> list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
More information about the swift-evolution
mailing list