Partial list of open Swift 3 design topics

Would it not be possible to replace NSRange with Range<String.Index> on the API surface area we control right now (I.e Foundation)? Foundation could also an extension on String which converts Range<String.Index> <-> NSRange so you can do explicit “bridging", since NSRange is a Foundation type. That’s what it currently does for NSRange<Int>?.

It would make life much easier for people only in Swift, and at the boundary with Obj-C — okay, it’s not really bridging as such, but is it really any more or less convenient to call a method than to perform an “as” cast? You might argue that it’s even more convenient to call a method, since you get code-completion telling you which Obj-C types you can bridge to (and possibly explaining why it’s unexpectedly an optional).

Karl

···

On 28 Jun 2016, at 18:29, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

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.

I’ll try to elaborate on the issues:

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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 27, 2016, at 10:40 PM, Charlie Monroe <charlie@charliemonroe.net> wrote:

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)?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This makes sense. If nobody objects I'll prepare a proposal today.

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@apple.com> wrote:

On Jun 27, 2016, at 10:40 PM, Charlie Monroe <charlie@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@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)?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I'd really love if there were a simple way to bind labels to any tuple, where they can then be referred to by those labels in the current scope as well as by .0, .1, and by any other existing labels, so long as there's no syntactic confusion between labels. Labels would inherently simplify to positions with argument names as semantic sugar. Default values (now in fixed order) maintain position numbers even when excluded.

For example: myArray.enumerate.tupleBind(index:, value:).map({ do stuff with $0.index, $0.value })

Too impossible? Against Swift philosophy?

-- E

···

On Jun 28, 2016, at 10:33 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 27, 2016, at 10:40 PM, Charlie Monroe <charlie@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

This makes sense. If nobody objects I'll prepare a proposal today.

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.

Well, *I* want to remove associated type inference because I feel that we shouldn’t have global inference like this in Swift. I am, however, concerned about the standard library’s ability to make conformances to the Collection protocols provide meaningful defaults for, e.g., the SubSequence associated type.

  - Doug

···

On Jun 28, 2016, at 9:49 AM, Austin Zheng <austinzheng@gmail.com> wrote:

Best,
Austin

Sent from my iPhone

On Jun 28, 2016, at 9:33 AM, Douglas Gregor <dgregor@apple.com> wrote:

On Jun 27, 2016, at 10:40 PM, Charlie Monroe <charlie@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@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)?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

···

On 28.06.2016 19:49, Austin Zheng via swift-evolution wrote:

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@apple.com> >> wrote:

On Jun 27, 2016, at 10:40 PM, Charlie Monroe >>> <charlie@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@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)?

-Chris

_______________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________ swift-evolution mailing
list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@apple.com> >>> wrote:

On Jun 27, 2016, at 10:40 PM, Charlie Monroe >>>> <charlie@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@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)?

-Chris

_______________________________________________
swift-evolution mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________ swift-evolution mailing

list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I am also +1 on the concept, but haven’t had a chance to fully consider the ramifications.

-Chris

···

On Jun 28, 2016, at 11:00 AM, Douglas Gregor <dgregor@apple.com> wrote:

On Jun 28, 2016, at 9:49 AM, Austin Zheng <austinzheng@gmail.com> wrote:

This makes sense. If nobody objects I'll prepare a proposal today.

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.

Well, *I* want to remove associated type inference because I feel that we shouldn’t have global inference like this in Swift. I am, however, concerned about the standard library’s ability to make conformances to the Collection protocols provide meaningful defaults for, e.g., the SubSequence associated type.

I am also for removing associated type inference, and I guess if it needs to be done, its now. Concerning SubSequence, isn’t that supposed to be away post Swift-3 once we have some of the more powerful generics?

···

On 28 Jun 2016, at 20:00, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Well, *I* want to remove associated type inference because I feel that we shouldn’t have global inference like this in Swift. I am, however, concerned about the standard library’s ability to make conformances to the Collection protocols provide meaningful defaults for, e.g., the SubSequence associated type.

  - Doug

I'm not aware of any generics features that will allow us to remove SubSequence.

Dmitri

···

On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

On 28 Jun 2016, at 20:00, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote:

Well, *I* want to remove associated type inference because I feel that we
shouldn’t have global inference like this in Swift. I am, however, concerned
about the standard library’s ability to make conformances to the Collection
protocols provide meaningful defaults for, e.g., the SubSequence associated
type.

- Doug

I am also for removing associated type inference, and I guess if it needs to
be done, its now. Concerning SubSequence, isn’t that supposed to be away
post Swift-3 once we have some of the more powerful generics?

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

I would be very concerned about performance regressions because of
SubSequence being defined as an existential.

Dmitri

···

On Tue, Jun 28, 2016 at 10:03 PM, David Waite <david@alkaline-solutions.com> wrote:

On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution > <swift-evolution@swift.org> wrote:

On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote:

I am also for removing associated type inference, and I guess if it needs to
be done, its now. Concerning SubSequence, isn’t that supposed to be away
post Swift-3 once we have some of the more powerful generics?

I'm not aware of any generics features that will allow us to remove
SubSequence.

Generalized existentials provide an intelligent default value on Sequence
for SubSequence and Iterator, if Element was an associated type. There would
still be efficiencies possible if you were able to specify these associated
types as concrete types.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

Generalized existentials provide an intelligent default value on Sequence for SubSequence and Iterator, if Element was an associated type. There would still be efficiencies possible if you were able to specify these associated types as concrete types.

-DW

···

On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution <swift-evolution@swift.org> wrote:

On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am also for removing associated type inference, and I guess if it needs to
be done, its now. Concerning SubSequence, isn’t that supposed to be away
post Swift-3 once we have some of the more powerful generics?

I'm not aware of any generics features that will allow us to remove SubSequence.