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

> On 28 Jun 2016, at 18:29, Douglas Gregor via swift-evolution > wrote: > >> >> On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution >> wrote: >> >> >>> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution >>>

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

On Tue, Jun 28, 2016 at 10:03 PM, David Waite wrote: > > On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution > wrote: >

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

> On Jun 28, 2016, at 10:15 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Tue, Jun 28, 2016 at 3:49 PM, David Hart via swift-evolution > > wrote: >> >> >> I am also for removing associated type

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

> On Jun 28, 2016, at 11:00 AM, Douglas Gregor wrote: > > >> On Jun 28, 2016, at 9:49 AM, Austin Zheng 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

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

> On Jun 28, 2016, at 7:36 AM, Wallacy wrote: > > And something about Property Behaviors? It's a very good proposal, and can > solve many problems cited in other proposals in this list. I’m also looking forward to property behaviors, but there is a ton of open design work

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

> On 28 Jun 2016, at 20:00, Douglas Gregor via swift-evolution > 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

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

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,

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

> On Jun 28, 2016, at 9:49 AM, Austin Zheng 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

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

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

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

> On Jun 28, 2016, at 10:33 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Jun 27, 2016, at 10:40 PM, Charlie Monroe >> wrote: >> >> Oh, I see. The issue is then the following: >> >> let x = f >> x(1, 2) // Error: Missing

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

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

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

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

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

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

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

> On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution > wrote: > > >> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution >> wrote: >> >> >>> - Bridge NSRange to “Range?” >> >> I don’t think I can handle writing a

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

> On Jun 24, 2016, at 9:22 AM, 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: > >

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

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

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

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... > On Jun 28, 2016, at 7:06 AM, Austin

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

> On 27 Jun 2016, at 00:57, Russ Bishop via swift-evolution > wrote: > > >> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution >> wrote: >> >> >>> - Bridge NSRange to “Range?” >> >> I don’t think I can handle writing a

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

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

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

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

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

> On Jun 24, 2016, at 11:30 PM, Austin Zheng 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

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

> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution > wrote: > > >> - Bridge NSRange to “Range?” > > I don’t think I can handle writing a proposal for this one, but I’d die for > it. > ___ > swift-evolution

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

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

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

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 :

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

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: http://thread.gmane.org/gmane.comp.lang.swift.evolution/3915/ https://bugs.swift.org/browse/SR-586 I mention

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

> - Bridge NSRange to “Range?” 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

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

> - Bool is a simple enough concept to not need a family of protocols. Literally, the most fundamental concept. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

On Jun 22, 2016, at 6:16 PM, Xiaodi Wu wrote: > - Remove Boolean protocol. > ^^^ > What's the thinking behind this particular item? > “Boolean” isn’t pulling its weight: - It only abstracts over Bool and ObjCBool. - It only enables a few operations on ObjCBool, which are

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

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,

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

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

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

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