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

[Vladimir.S]

On 24.06.2016 19:22, Paul Cantrell via swift-evolution wrote:
> Way back when, there was an unresolved discussion was about whether it’s
> a bug or a feature that $0 sometimes captures a single arg and sometimes
> captures all args as a tuple:

Just recently I started a new thread for that subject : "[Discussion] 
func/closure parameters and tuples" but no replies for it yet. Was planing 
to start the proposal thread.

I believe we should add consistency in Swift regarding allowed arguments of 
closure/func.
Dropped questions regarding this here:
https://bugs.swift.org/browse/SR-1334
https://bugs.swift.org/browse/SR-1854

So I'll repeat questions/issues here in one place:

1. I was not expecting this will compile :

let ft1 : (Int,Int) -> Void = { x in print(x.0, x.1)}

ft1(1, 2)

the type of ft1 is definitely not the same as closure


2. The same. But this crashes compiler at compile time(bug is reported) :

let ft2 : (Int,Int) -> Void = { x in print(x) }

ft2(1, 2)

3. Was expecting closure will require a single argument, which is tuple; 
but it accepts even just x, y

typealias IntInt = (Int,Int)

func foo(block: (IntInt) -> Void) {
     let z : IntInt = (1,2)
     block(z)
}

foo { x in print(x)} // ok
foo { x, y in print(x,y)}
foo { (x, y) in print(x, y)}

I'm not sending two values to closure, I send one instance which is tuple.


4.

typealias BinaryIntOp_v1 = (Int, Int) -> Int
typealias BinaryIntOp_v2 = ((Int, Int)) -> Int

print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int  why?
print(BinaryIntOp_v2.self) // Prints ((Int, Int)) -> Int

let areRepresentingTheSameType = BinaryIntOp_v1.self == BinaryIntOp_v2.self 
// (alt-click the "==" and read doc.)
print(areRepresentingTheSameType) // Prints true

let add_v1: BinaryIntOp_v1 = (+)
let add_v2: BinaryIntOp_v2 = (+) // Or both could have been eg: { return $0 
+ $1 }

let ra = add_v1(1, 2)
let rb = add_v2((1, 2)) // NOTE: Needs these extra parens (otherwise error: 
"Extra argument in call")

let rc = (add_v1 as BinaryIntOp_v2)((1, 2)) // NOTE: I am type casting 
these to an identical type ...
let rd = (add_v2 as BinaryIntOp_v1)(1, 2)   // ... in order to swap which 
one of them need extra parens ...

>
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/
> https://bugs.swift.org/browse/SR-586
>
> I mention this because it would be a breaking change to make $0
> consistently capture the first arg, and I wonder whether that should be
> in the Swift 3?
>
> (If anybody wants to comment on the question, I recommend catching up on
> the discussion in the links above first.)
>
> Cheers, P
>
>
>> On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> Hi everyone,
>>
>> Here is a partial list of the open topics that the core team would
>> like to get resolved in Swift 3.  The list is partial both because I’m
>> way behind on swift-evolution traffic, but also because new things may
>> come up.  There are also a number of accepted proposals that are not
>> yet implemented.  Some topics have proposals done, and therefore have
>> an SE number, but the review discussion hasn’t finalized.  Some of
>> these topics have an “owner” that is driving or planning to start a
>> discussion on them them, which I’ve listed in square brackets.
>>
>> If you’d like to discuss these topics in particular, please start a
>> new thread specific to them, or contribute to an already-existing
>> thread discussing it.  Several of these don’t have an owner yet, so if
>> you’d like to pick them up and run with them, that would be great.
>> Thanks!
>>
>> -Chris
>>
>>
>> Language: - SE-0091: Improving operator requirements in protocols
>> [Core team discussed this, will email about it shortly] - SE-0077:
>> Improve operator declaration syntax [Core team discussed this, Joe
>> Groff will follow up on this soon] - SE-0095: Replace protocol<P1,P2>
>> syntax with P1 & P2 syntax - SE-0102: Remove @noreturn attribute and
>> introduce an empty NoReturn type - SE-0103: Invert @noescape - Remove
>> T -> T? implicit promotion for operands to operators - Removing
>> argument labels from the type system (so they are declaration-only
>> constructs) - Some reshuffling with requiring @objc/@nonobjc for
>> things that shouldn’t/can’t be expressed via the Objective-C runtime -
>> Eliminating inference of associated type witnesses (as is mentioned in
>> the generics manifesto) - Should public classes be
>> non-publicly-subclassable by default? [John McCall] - Revising access
>> modifiers on extensions [Adrian Zubarev]
>>
>>
>> Standard library: - SE-0101: Rename sizeof and related functions to
>> comply with API Guidelines - Ongoing API naming adjustments for
>> stdlib: - Closure arguments [Dave Abrahams] - Others are being
>> discussed on swift-evolution. - Remove Boolean protocol. - SE-0104:
>> Revise Integer protocols to match FP ones. [Max Moiseev]
>>
>> SDK / Cocoa / ObjC interop: - [SE-0086] Finalize NS removal plan.
>> [Tony Parker] - Importing “id” as Any [Joe Groff] - Revise
>> NSError/Error model for better interoperability and usability. [Doug
>> Gregor] - <rdar://15821981> Bridge NSRange to “Range<Int>?”
>>
>> _______________________________________________ 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
>