On 13.06.2017 3:35, John McCall wrote:
On Jun 12, 2017, at 6:42 PM, Vladimir.S <[email protected]> wrote:
John, could you clarify the details regarding function types, SE-0066 and
SE-0110 implementations *planned* for Swift 4 release? I believe all these are
important questions to be answered to understand the near feature of Swift and
to be prepared for changes.
It's not hard to figure out what any of these *should* do in Swift 4. I'm not
going to commit to promising that Swift 4 will not have bugs that cause
deviations from that. If the Core Team decides that something needs to happen
with parameter destructuring in Swift 4, that will not go without comment here.
Thank you for reply, but actually I was trying to figure out if I understand
correctly "what any of these *should* do in Swift 4". Also, it will be great if we
have a record of how such code at least *should* work in Swift 4, so we can refer to
this.
So, again, I'm asking you or some one from core team to spent 1 minute to reply so we
all have a clear view of expected results for this code. Thank you.
I do believe this is very important in lights of current debates regarding SE-0110
changes(actually, I insist, more correct implementations of SE-0066) and probably can
help to avoid the same problem after "bugs" will be fixed.
Btw, it is *very* strange for me that you are calling current behavior as "bugs", and
even strange that these long-running "bugs" can be still with us in Swift 4 (note:
SE-0066 and SE-0110 was accepted to be implemented in *Swift 3*).
And more important, as I understand, fixing these "bugs" will lead to *source
breaking* changes, that is not possible for long time after Swift 4 release.
Plus, keeping these "bugs" leaves Swift in very broken state : we broke what was
allowed in Swift 3 to fix the type system, but still have type system broken *in the
same exact place*.
I really can't understand this. It is fundamentally that
type(of: fooParam) == type(of: fooTuple) even in Swift 4, it is not just a little
"bug", code *will* use this "feature" and then we'll have a very loud voices about
regressions in Swift if such "bug" will be "fixed". The same is for
fooParam is ((Int,Int))->() and fooTuple is (Int,Int)->() and so on.
I can't see how this could be a bug fixing - it is fundamental changes in allowed
syntax and in type system. And so this couldn't be done after Swift 4 release. No?
About this:
----
On 13.06.2017 2:24, Jens Persson wrote:
> This: https://twitter.com/slava_pestov/status/874394132340289536
> seems to suggest that the current Swift 4 behavior will not change much in this
domain.
>
----
It will be really *nice* to have a more detailed reply from core team regarding all
this situation with SE-0025, SE-0066, SE-0110 implementations in Swift 4 and the
"bugs" mentioned in my message, here in official swift evolution email list.
Vladimir.
John.
Given :
func fooParam(_ x: Int, _ y: Int){}
func fooTuple(_ x: (Int, Int)) {}
and
var closureParam = { (x: Int, y: Int) in print("in closureParam") }
var closureTuple = { (x: (Int, Int)) in }
* What will be the result in Swift 4 release? :
1. type(of:fooParam)
2. type(of:fooTuple)
3. type(of:closureParam)
4. type(of:closureTuple)
* Will this be true in Swift 4 release? :
1. type(of: fooParam) == type(of: fooTuple)
2. fooParam is ((Int,Int))->()
3. fooTuple is (Int,Int)->()
4. type(of: closureParam) == type(of: closureTuple)
5. closureParam is ((Int,Int))->()
6. closureTuple is (Int,Int)->()
* Will this code still be valid in Swift 4 release? :
1.
closureTuple = closureParam
closureTuple((1,2)) // prints "in closureParam"
2.
var f: () -> Int = { 5 } // function with no parameters
var g: (()) -> Int = { 5 } // function taking a single () parameter
f = g
f()
* Does core team plan to introduce some syntactic sugar for tuple argument
destructuring in closures *before* Swift 4 release?
If so, what do you think about a suggestion to allow type inference for
currently allowed syntax for tuple argument destructuring? I.e.
allowed: .filter {(friend: (name: String, age: Int)) in friend.age >= 18 }
proposed: .filter {(friend: (name, age)) in friend.age >= 18 }
* And the same for passing function with no parameters if function with single
Void parameter is expected? I.e. in such situation:
func foo<T>(_ callback: (T)->Void) {}
func bar(){}
foo(bar)
Thank you for your time.
Vladimir.
On 12.06.2017 20:15, John McCall via swift-evolution wrote:
On Jun 12, 2017, at 4:48 AM, Jérémie Girault via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Hi here,
As I tested swift4 in xcode9b1 I noticed a lot of regressions about tuples
usage.
After documenting myself about the changes which happened, I thought that they
could be improved. Instead of fighting these propositions (which make sense), I
wanted create a few proposal which would improve these recent changes with a
few simple rules.
My propositions are based on the recent decisions and in the continuation of
SE-0110. The first one is about Void.
Void is historically defined as the type of the empty tuple. The reason of this
is that arguments were initially considered as tuple.
The dominant consideration here was always return types, not parameters. I'm
not sure there was ever much point in writing Void in a parameter list, but
whatever reasons there were surely vanished with SE-0066.
Note that 'void' in C was originally exclusively a return type. ANSI gave it a
new purpose it with void*, but the meaning is totally unrelated.
John.
_______________________________________________
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
