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>?”
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.
^^^
What's the thinking behind this particular item?
···
On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
- 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>?”
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:
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@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>?”
Would you be willing to elaborate a bit on "Removing argument labels from the type system"? The bulk of this went away when tuple splatting was removed, and values of function type already seem to ignore the labels of the functions they are assigned.
Best,
Austin
···
On Jun 22, 2016, at 6:07 PM, Chris Lattner via swift-evolution <swift-evolution@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>?”
And something about Property Behaviors? It's a very good proposal, and can
solve many problems cited in other proposals in this list.
···
Em qua, 22 de jun de 2016 às 22:08, Chris Lattner via swift-evolution < swift-evolution@swift.org> escreveu:
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>?”
I'd be happy to put together proposals for associated type inference
removal and removing type system significance from argument labels, if
nobody else wants them.
Austin
···
On Wed, Jun 22, 2016 at 6:16 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote:
On Wed, Jun 22, 2016 at 8:07 PM, Chris Lattner via swift-evolution < > swift-evolution@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.
^^^
What's the thinking behind this particular item?
- 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>?”
“Boolean” isn’t pulling its weight:
- It only abstracts over Bool and ObjCBool.
- It only enables a few operations on ObjCBool, which are not very important.
- ObjCBool is a bridging problem, and we don’t handle bridging by introducing common protocols (e.g. in the case of String vs NSString, we don’t introduce a common “Stringable” protocol.
Further, it complicates the model:
- People are confused by it and the similar but very different Bool type.
- Bool is a simple enough concept to not need a family of protocols.
···
On Jun 22, 2016, at 6:16 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
- Remove Boolean protocol.
^^^
What's the thinking behind this particular item?
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:
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 ...
···
On 24.06.2016 19:22, Paul Cantrell via swift-evolution wrote:
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@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>?”
Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad.
Russ
···
On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
- <rdar://15821981> Bridge NSRange to “Range<Int>?”
I don’t think I can handle writing a proposal for this one, but I’d die for it.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
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.
-Chris
···
On Jun 24, 2016, at 11:30 PM, Austin Zheng <austinzheng@gmail.com> wrote:
Would you be willing to elaborate a bit on "Removing argument labels from the type system"? The bulk of this went away when tuple splatting was removed, and values of function type already seem to ignore the labels of the functions they are assigned.
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:
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.)
I consider this a bug. The removal of implicit tuple splats should, IMO, encompass making $0 consistently capture the first argument. I’d love for this to happen in Swift 3.
- Doug
···
On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution <swift-evolution@swift.org> wrote:
Cheers, P
On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution <swift-evolution@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>?”
This is a good point. I asked @CC Tony Parker recently about doing the conversion inside Foundation and just exposing Range<String.Index> directly.
Basically everybody who uses those Foundation methods which return an NSRange for strings needs to write their own conversion functions anyway, and less-experienced developers might not get the UTF-16 thing correct. That’s something we should be handling for them; it’s an implementation detail of the underlying CoreFoundation APIs.
Karl
···
On 27 Jun 2016, at 00:57, Russ Bishop via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
- <rdar://15821981> Bridge NSRange to “Range<Int>?”
I don’t think I can handle writing a proposal for this one, but I’d die for it.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad.
1) NSRange could be mapped to Range<Int>. This would involve executing bridging code (much like we do for String <-> NSString or Bool <-> BOOL), because NSRange’s location + length representation is different from Range’s lowerBound/upperBound.
2) Some NSRanges use location == NSNotFound to indicate “no value”. We would want to bridge these NSRanges to a Range<Int>?, where we location == NSNotFound maps to nil. We cannot guess whether the range treats NSNotFound as special from the API: we’ll need some kind of annotation (e.g., via some kind of Objective-C attribute) that indicates that we should be mapping to an optional value as well as how to identify the nil value. That attribute would then have to be applied to popular APIs.
3) When the NSRange is describing indices into a String, we’d need some kind of Objective-C attribute to say that these are indices and (possibly?) point to which NSString* they reference (although the latter is not strictly necessary in the new collection indexing model), so that NSRange can be mapped to Range<String.Index> or Range<String.Index>? (so it needs to compose with #2). That attribute would then have to be applied to popular APIs.
4) Similar to #3, we should do the same thing for NSIntegers that represent locations in a String, so those NSIntegers can get mapped to String.Index. There are likely conventions that would map to String.Index? as well, so this also calls for a generalization of #2. That attribute would then have to be applied to popular APIs..
Although this is on my personal list of things that would be great to clean up for Cocoa, it doesn’t seem feasible for Swift 3 to get it designed, implemented, and rolled out to enough APIs .
- Doug
···
On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:
- <rdar://15821981> Bridge NSRange to “Range<Int>?”
I don’t think I can handle writing a proposal for this one, but I’d die for it.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Will this work the way people expect, especially given how NSString handles unicode vs Swift String and the various views? My suspicion is at least a chunk of the things people imagine doing with the bridged NSRange won’t actually work and they’ll be sad.
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:
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.)
I consider this a bug. The removal of implicit tuple splats should, IMO,
encompass making $0 consistently capture the first argument. I’d love
for this to happen in Swift 3.
Doug, could you please comment this related thread in mailing list: "[Proposal] Disallow
implicit conversion between function/closure with a list of parameters and
with tuple parameter. Remove function type inconsistency."
···
On 28.06.2016 18:55, Douglas Gregor via swift-evolution wrote:
On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> wrote:
- Doug
Cheers, P
On Jun 22, 2016, at 8:07 PM, Chris Lattner via swift-evolution >>> <swift-evolution@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>?”
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@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)?
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...
···
On Jun 28, 2016, at 7:06 AM, Austin Zheng <austinzheng@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@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)?