[swift-evolution] Partial list of open Swift 3 design topics

[Austin Zheng]

Hi Vladmir,

I read your thread earlier and thought you raised some really good points.
Are you planning on preparing a proposal? If not, I'd be happy to fold your
ideas in to make one big proposal. If you are already preparing one, you
should just fold Doug's point into your proposal.

Best,
Austin

On Tue, Jun 28, 2016 at 10:30 AM, Vladimir.S <svabox at gmail.com> wrote:

> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160628/498e3c85/attachment.html>