Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

typealias Point = (x: Int, y: Int) typealias Dimensions = (x: Int, y: Int) let point: Point = (x: 5, y: 5) let dimensions = point Fundamentally different concepts may have labels happen to be the same. Structs protect against this conversion, tuples don't. Explicit protocol conformance is just

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt wrote: > Tuples are inherently interchangable. If you want to avoid this, the > safest way is to use a struct. > ``` typealias Foo = (a: Int, b: Int) typealias Bar = (c: Int, d: Int) var foo: Foo = (1, 2) var bar: Bar = (3, 4) foo = bar ``` ERROR at

Re: [swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

> * What is your evaluation of the proposal? Oh, so *that's* what it's for. (That's a +1.) -- Brent Royal-Gordon Architechies ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Tuples are inherently interchangable. If you want to avoid this, the safest way is to use a struct. Labels/naming shouldn't be relied on to provide type information, this is why implicit conformance to protocols is disallowed. From James F > On 2 Jul 2016, at 06:43, Xiaodi Wu wrote: > > What

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

What's the basis for your claim that tuples are best passed around without their labels? If I have `typealias CartesianCoordinates = (x: Double, y: Double)`, these labels are absolutely meaningful, and I would not want them to be interchangeable with a hypothetical `typealias PolarCoordinates = (r:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols

> > https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md Frankly, every name mentioned in that proposal basically sucks, including the old name, the new name, and all of the alternative names. I'm currently thinking about `WhateverLiteralCandidat

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

> On Jul 1, 2016, at 9:11 PM, David Waite via swift-evolution > wrote: > > +1! > > To me, it feels like the ambivalent dynamic casting is a temporary > complexity, and that at some point in the future the need to expose legacy > reference types like NSString outside swift-supplied or user-cr

[swift-evolution] Bridging Python Packages to Swift

Hey everyone, I lack the experience the rest of the people in this list probably have being an undergraduate student but I would love to participate in this language because I see its potential. With that being said, one of the biggest advantages python has is its immersive number of packages tha

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 8:25 PM, Brent Royal-Gordon via swift-evolution > wrote: > > * I think we need the word "localized" on the properties of `LocalizedError`. > The fact that they're localized is a very important semantic, and I don't > think the fact that they come from a protocol called "Lo

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + > annotations’ relevant to use in parameter lists. If you can restrict this > pseudo-type to the appropriate context, like we are heading towards with > disallowing ImplicityUnwrappedOptional in function signatures, why no

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 2 Jul 2016, at 05:03, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:55 PM, James Froggatt wrote: >> >> >> On 2 Jul 2016, at 04:46, Austin Zheng wrote: >> >>> >>> >>> This functionality naturally falls out of any decent proposal for variadic >>> generics. I'd rather wait until we

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

> > > We might even be able to take the existing string-to-integer > > logic, which I believe is duplicated for each type through GYB, and > > share it in an extension so no Integer needs to write its own > > conversion. Is that something that should be added? > > https://github.com/apple/swift/blo

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

+1! To me, it feels like the ambivalent dynamic casting is a temporary complexity, and that at some point in the future the need to expose legacy reference types like NSString outside swift-supplied or user-created bridging code will disappear completely. This also will get rid of some of the

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 8:55 PM, James Froggatt wrote: > > > On 2 Jul 2016, at 04:46, Austin Zheng > wrote: > >> >> >> This functionality naturally falls out of any decent proposal for variadic >> generics. I'd rather wait until we can re-add it in a principled m

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

Sorry, this was meant to be in response to: https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md From James F > On 2 Jul 2016, at 04:02, James Froggatt wrote: > > I've made a separate topic discussing the possible consequences of this > change, but

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 2 Jul 2016, at 04:46, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:37 PM, James Froggatt wrote: >> >> >> On 2 Jul 2016, at 04:22, Austin Zheng wrote: >> >>> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution wrote: ‘If I understand the other disc

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 8:37 PM, James Froggatt wrote: > > > On 2 Jul 2016, at 04:22, Austin Zheng > wrote: > >> >>> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> ‘If I understand the other di

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On 2 Jul 2016, at 04:22, Austin Zheng wrote: > > >> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution >> wrote: >> >> ‘If I understand the other discussions regarding the evolution of Swift's >> function arguments model, the similarity to tuples with labeled components >> is

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution > wrote: > > ‘If I understand the other discussions regarding the evolution of Swift's > function arguments model, the similarity to tuples with labeled components is > a historical artifact and now merely coincidental.’ It's b

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

Somehow managed to post in the wrong thread, sorry. See: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023221.html From James F > On 30 Jun 2016, at 19:22, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0110: Distinguish between single-tuple and

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

Sorry, this was meant to be in response to: https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md Begin Message Group: gmane.comp.lang.swift.evolution MsgID: I've made a separate topic discussing the possible consequences

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

‘If I understand the other discussions regarding the evolution of Swift's function arguments model, the similarity to tuples with labeled components is a historical artifact and now merely coincidental.’ Is it though? Couldn't the current confusing situation of tuple labels in the type system b

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

on Fri Jul 01 2016, Matthew Johnson wrote: > Sent from my iPad > >> On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> on Wed Jun 29 2016, Matthew Johnson wrote: >>> >>> Sent from my iPad >>> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolutio

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0111: Remove type system significance of function argument labels

I've made a separate topic discussing the possible consequences of this change, but I don't think the implications are really worth it. Parameter lists and tuples are fundamentally similar, and that's why we're getting all of these confusing edge cases. Ultimately, this come down to two problem

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jul 1, 2016, at 6:32 PM, Dave Abrahams wrote: >> >> >> on Fri Jul 01 2016, Matthew Johnson > > wrote: >> > On Jul 1, 2016, at 11:51 AM, Dave Abrahams >>> > wrote:

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 6:32 PM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Matthew Johnson > wrote: > >>> On Jul 1, 2016, at 11:51 AM, Dave Abrahams >> > wrote: >>> >>> >>> on Fri Jul 01 2016, Matthew Johnson >>

Re: [swift-evolution] Variadics through tuples

So what's the official stance on this? Is SE0029 specifically prohibiting the use of tuple splat as pure syntactic sugar? Or does it extend to… Tuple splat in generic contexts: function(a: A, b: (A) -> B) -> B { b(a) } function(a: tupleValue, b: splattableFunction) Explicit casts, of the

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> * What is your evaluation of the proposal? Massively in favor overall. I use NSError features heavily in Objective-C, and I'll be very, very glad to get powerful error bridging in Swift. I don't think it's mentioned anywhere, but are the new protocols in Foundation or Stdlib? I'm hoping

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

> Vladimir.S via swift-evolution writes: Following your conclusion, should this be legal as well? let f: () -> Void = { x in print(x) } // f() prints "()" let f: (Int) -> Void = { x in print(x) } // f(5) prints "5" In other words, "0 argument" is an impossible scenario?

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

I'm really happy to see this. It cleans things up and enables some really important things such as more idiomatic bridging (NSNumber to native numeric types is amazing!). The ideas mentioned will really help to make Cocoa feel as Swifty as possible. Sent from my iPad > On Jul 1, 2016, at 6:3

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

Sent from my iPad > On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 29 2016, Matthew Johnson wrote: >> >> Sent from my iPad >> >>> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> I've updated my pull reques

Re: [swift-evolution] [Discussion] Rename BitwiseOperations protocol

on Fri Jul 01 2016, Riley Testut wrote: > Hi all, > > This is probably very minor, but I’m not sure the protocol name > “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what > the guidelines have to say about protocol names: > > Protocols that describe what something is should re

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 5:25 PM, Charles Srstka wrote: > >> On Jul 1, 2016, at 4:12 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> FYI, in-progress implementation is available at: >> >> https://github.com/apple/swift/tree/nserror-bridging >>

Re: [swift-evolution] renaming CustomStringConvertible

on Fri Jul 01 2016, Dmitri Gribenko wrote: > On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution > wrote: >> >> To the Swift community, >> >> May I put forth a couple of new names for the following protocol: >> >> >> - CustomStringConvertible — rename as ‘Descriptive’ or as

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 4:12 PM, Douglas Gregor via swift-evolution > wrote: > > FYI, in-progress implementation is available at: > > https://github.com/apple/swift/tree/nserror-bridging > > > The only issue I’ve found so far with the

Re: [swift-evolution] [Review] SE-0104: Protocol-oriented integers

on Wed Jun 29 2016, Brent Royal-Gordon wrote: > We might even be able to take the existing string-to-integer > logic, which I believe is duplicated for each type through GYB, and > share it in an extension so no Integer needs to write its own > conversion. Is that something that should be added?

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

on Wed Jun 29 2016, Matthew Johnson wrote: > Sent from my iPad > >> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> I've updated my pull request with a much more conservative set of >> changes that preserves/restores label-free-ness for all “term of art” >>

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

on Wed Jun 29 2016, Anton Zhilin wrote: > Dave Abrahams via swift-evolution writes: > >> I've updated my pull request with a much more conservative set of >> changes that preserves/restores label-free-ness for all “term of art” >> functional methods such as filter and reduce. >> >> https://git

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

on Fri Jul 01 2016, Adrian Zubarev wrote: > The only problem I can see with ExpressibleAs is that it also reads if > I could potentially do something like this type <-> literal, People keep going down that road, but I don't see why. As far as I know, “A is expressible as B” has never implied

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

> Joe Groff via swift-evolution writes: +1. id => AnyObject made more sense then just as id =>Any makes more sense now (now that things from Objective-C have value semantics more commonly). ___ swift-evolution mailing list swift-evolution@swift.org ht

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

+1 from me I think that it makes sense since there exists now a possibility for Obj-C types to come in as types with value semantics. TJ On Fri, Jul 1, 2016 at 7:37 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone. After implementing SE-0072, disabling the imp

[swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

Hi everyone. After implementing SE-0072, disabling the implicit bridging conversions from Swift value types to classes (https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md), we immediately observed a severe negative impact on Cocoa inter

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

+1 if SE-0111 is accepted. 0 otherwise. On Fri, Jul 1, 2016 at 7:34 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 02.07.2016 1:49, Daniel Duan via swift-evolution wrote: > >> Chris Lattner via swift-evolution writes: >> >> I think there's an edge case that needs con

Re: [swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0111: Remove type system significance of function > argument labels" begins now and runs through July 4. The proposal is > available here: > > > htt

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0115: Rename Literal Syntax Protocols

I’d prefer the “namespace" idea, but a big +1 either way. - Dave Sweeris > On Jul 1, 2016, at 6:07 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0115: Rename Literal Syntax Protocols" begins now and runs > through July 7. The proposal is available here: > >

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

On 02.07.2016 1:49, Daniel Duan via swift-evolution wrote: Chris Lattner via swift-evolution writes: I think there's an edge case that needs consideration: when there's zero expected arguments and the '_' parameter is used: let f: () -> Void = { _ in } As I understand current syntax and logi

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Matthew Johnson wrote: >> On Jul 1, 2016, at 11:51 AM, Dave Abrahams wrote: >> >> >> on Fri Jul 01 2016, Matthew Johnson > > wrote: >> > On Jun 30, 2016, at 12:26 PM, Dave Abrahams >>> wrote: on Wed Jun 29 2016, Ha

Re: [swift-evolution] [Pitch] Self.withoutSpecialization

Bump On Fri, Jul 1, 2016 at 11:56 AM, T.J. Usiyan wrote: > > > ## The Issue > Given > ``` swift > public protocol Zipper1D : CustomStringConvertible { > associatedtype Element > } > ``` > > We can almost write a `flatMap` which keeps the general identity of self > and swaps out the Element

Re: [swift-evolution] Variadics through tuples

> On Jul 1, 2016, at 4:05 PM, Vladimir.S via swift-evolution > wrote: > > On 02.07.2016 0:42, James Froggatt wrote: >> Thanks for pointing out the warning, I wouldn't have known otherwise. I >> tested using ‘try’ on a non-throwing function in the iOS Swift Playgrounds >> app, and didn't get a

[swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Hello Swift community, The review of "SE-0115: Rename Literal Syntax Protocols" begins now and runs through July 7. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md Reviews are an important part of the Swift

Re: [swift-evolution] Variadics through tuples

On 02.07.2016 0:42, James Froggatt wrote: Thanks for pointing out the warning, I wouldn't have known otherwise. I tested using ‘try’ on a non-throwing function in the iOS Swift Playgrounds app, and didn't get a warning. The app doesn't seem to give warnings, only errors. Relatedly, I think b

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Tue Jun 28 2016, Jonathan Hull wrote: >> On Jun 28, 2016, at 10:51 AM, Dave Abrahams wrote: >> 1. Presumably these are all for-in-able. What makes something for-in-able? >>> >>> I would think the potentially infinite should require for-in-until >>> (even if you explicitly set u

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

on Thu Jun 23 2016, Brent Royal-Gordon wrote: > As previously threatened mentioned, I've written a draft proposal to > fix a number of naming issues with APIs operating on the beginning and > end of Sequences and Collections: > > • Inconsistent use of `prefix`/`suffix` vs. `first`/`last` > • Con

Re: [swift-evolution] Fwd: [Draft] Rationalizing Sequence end-operation names

on Thu Jun 23 2016, Xiaodi Wu wrote: > Yikes, not only is the email too big for some mail clients, it's too big > for the mailing list. Resending with proposal snipped. > > On Thu, Jun 23, 2016 at 1:24 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > >> Most of your pro

[swift-evolution] [Returned for Revision] SE-0091: Improving operator requirements in protocols

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md Hello Swift Community, The review of "SE-0091: Improving operator requirements in protocols" ran from May 17...23. While many people were positive about improving lookup of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md > > >

Re: [swift-evolution] [Review] SE-0110: Distinguish between single-tuple and multiple-argument function types

Chris Lattner via swift-evolution writes: I think there's an edge case that needs consideration: when there's zero expected arguments and the '_' parameter is used: let f: () -> Void = { _ in } According to the proposal, this is syntactically incorrect ( 0 != 1 ). But it is legal now since '_'

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

> > * What is your evaluation of the proposal? +1. Echoing what others have already said, this is a much better name. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and direction of

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 11:51 AM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Matthew Johnson > wrote: > >>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams >> wrote: >>> >>> >>> on Wed Jun 29 2016, Haravikk wrote: >>> >> > On 29 Jun 2016, at 00:10, Ma

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 11:54 AM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Matthew Johnson > wrote: > >>> On Jul 1, 2016, at 9:47 AM, Dave Abrahams wrote: >>> >>> >>> on Fri Jul 01 2016, Haravikk wrote: >>> >> > On 30 Jun 2016, at 23:39, Dave Ab

Re: [swift-evolution] [Proposal] Sealed classes by default

> On 1 Jul 2016, at 17:47, John McCall wrote: > > I don't think we'd ever use a compound keyword that starts with public; > we'd just separate them and say that the second half can only be present > on a public declaration, or do this parenthesized syntax. The `super` keyword could be reused:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0113: Add integral rounding functions to FloatingPoint

+1. These additions are appreciated and well thought out. > On Jun 30, 2016, at 11:02 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0113: Add integral rounding functions to FloatingPoint" > begins now and runs through July 5. The proposal is available here: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

+1. The use of the term header to describe this is much more clear than value. > On Jul 1, 2016, at 2:53 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of 'SE-0114: Updating Buffer "Value" Names to "Header” Names' > begins now and runs through July 7. The proposal is avail

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Yeah, I’ve been wondering if there’d ever be a way to convert something into a *Literal… I can’t think of why, other than as a way to cast between types which are both “ExpressibleAs*Literal", but then the protocol would have to be strengthened to indicate that the conversion had to be lossless.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

(inline) > On Jul 1, 2016, at 2:53 PM, Chris Lattner wrote: > > The goal of the review process is to improve the proposal under review > through constructive criticism and contribute to the direction of Swift. When > writing your review, here are some questions you might want to answer in your

[swift-evolution] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

Hello Swift community, The review of 'SE-0114: Updating Buffer "Value" Names to "Header” Names' begins now and runs through July 7. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0114-buffer-naming.md Reviews are an important part of the

Re: [swift-evolution] Variadics through tuples

Thanks for pointing out the warning, I wouldn't have known otherwise. I tested using ‘try’ on a non-throwing function in the iOS Swift Playgrounds app, and didn't get a warning. The app doesn't seem to give warnings, only errors. Relatedly, I think bracketless T -> T should be an error, not a

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

The only problem I can see with ExpressibleAs is that it also reads if I could potentially do something like this type <-> literal, but the direction type -> literal is impossible. --  Adrian Zubarev Sent with Airmail Am 1. Juli 2016 um 23:33:19, Matthew Johnson via swift-evolution (swift-ev

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jul 1, 2016, at 3:59 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Fri, Jul 1, 2016 at 1:35 PM, Dave Abrahams via swift-evolution > wrote: >> I think if `Syntax.IntegerLiteral` is actually unclear then the best >> cure is `ExpressibleAsIntegerLiteral` (no namespace needed). Non

Re: [swift-evolution] Variadics through tuples

Thanks. I agree, a standard library operator would clearly be the preferred way to do this, at least for general use. Basing it upon the ‘as’ cast just means we don't have to have to deal with another magical operator (looking at the inability to overload ‘!’ and ‘?’), as well as easing the tran

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

> On Jun 29, 2016, at 10:55 PM, Douglas Gregor wrote: > > You're talking about recursive protocol constraints (which would help > collapse some of the underscored protocols) and where clauses on associated > types in particular? I'm also talking about "caveman inference" if that's judged to be

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

FYI, in-progress implementation is available at: https://github.com/apple/swift/tree/nserror-bridging The only issue I’ve found so far with the proposal is this bit: When we introduce this bridging, we will need to remove NS

Re: [swift-evolution] Variadics through tuples

On 01.07.2016 23:55, James Froggatt wrote: Thanks for the response. I understand function overloading is possible, but it isn't nearly as convinient. Yes, agree. However, if explicit conversion is the way forward, then in the spirit of keeping backwards-compatibility in some form, we coul

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

Oh awesome! We'll definitely switch to that. Thanks! -- Keith Smiley On 07/01, Alex Migicovsky wrote: > Hi Keith, > > As a small aside, I’d suggest using ObjectIdentifier instead of a String to > back your TypeRepresentation struct. ObjectIdentifier is Hashable and it has > an initializer that

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> * What is your evaluation of the proposal? +1. I would like to see .awayFromZero added as an option as well. It is occasionally useful, and it would provide symmetry. I would also like to see rounding precision as well, but that can be added later, so don’t let it stop this proposal > * Is

Re: [swift-evolution] [Probe] The automatically generated init for structs

Thank you > On Jul 1, 2016, at 4:24 PM, Chris Lattner wrote: > > >> On Jul 1, 2016, at 4:09 AM, Daniel Steinberg via swift-evolution >> wrote: >> >> My apologies if this was resolved before. >> >> At one point there was a suggestion for the access level for the >> auto-generated init for

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

On Fri, Jul 1, 2016 at 1:35 PM, Dave Abrahams via swift-evolution wrote: > I think if `Syntax.IntegerLiteral` is actually unclear then the best > cure is `ExpressibleAsIntegerLiteral` (no namespace needed). None of > the other suggestions I've seen describe what the protocol means as well > as th

Re: [swift-evolution] Variadics through tuples

Thanks for the response. I understand function overloading is possible, but it isn't nearly as convinient. However, if explicit conversion is the way forward, then in the spirit of keeping backwards-compatibility in some form, we could simply allow this: let paramsClosure: (Int, Int) -> () = …

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

On 01.07.2016 23:39, Xiaodi Wu via swift-evolution wrote: I thought your suggestion of IntegerLiteralExpressible (with or without Syntax) was nice too. Support. I still believe that Syntax.IntegerLiteralExpressible is the best. We see 'Syntax' first, then 'Integer' just after point, 'Expressibl

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

on Fri Jul 01 2016, Xiaodi Wu wrote: > On Fri, Jul 1, 2016 at 11:51 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jul 01 2016, Matthew Johnson wrote: >> >> >> On Jun 30, 2016, at 12:26 PM, Dave Abrahams >> > wrote: >> >> >> >> >> >> on Wed Jun 29 20

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I thought your suggestion of IntegerLiteralExpressible (with or without Syntax) was nice too. On Fri, Jul 1, 2016 at 15:35 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jul 01 2016, Erica Sadun wrote: > > > The best way to pass the Dave Test is to ask him direct

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

Sent from my iPad > On 1 Jul 2016, at 08:02, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0113: Add integral rounding functions to FloatingPoint" > begins now and runs through July 5. The proposal is available here: > > > https://github.co

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

on Fri Jul 01 2016, Erica Sadun wrote: > The best way to pass the Dave Test is to ask him directly, for example: > > Dave: > > Do you think the stdlib team would be okay with a naming scheme like > Syntax.Literal.ArrayProtocol, Syntax.Literal.IntegerProtocol, etc. We think > this produces a c

Re: [swift-evolution] [Probe] The automatically generated init for structs

> On Jul 1, 2016, at 4:09 AM, Daniel Steinberg via swift-evolution > wrote: > > My apologies if this was resolved before. > > At one point there was a suggestion for the access level for the > auto-generated init for structs. The issue was that the access level is > internal by default. If

Re: [swift-evolution] [Proposal] Union Type

> On Jul 1, 2016, at 2:06 AM, Cao Jiannan via swift-evolution > wrote: > > https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md > > > > Hi, > > I'm now officially proposal th

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> On 1 Jul 2016, at 14:13, Taras Zakharko via swift-evolution > wrote: > >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and contribute to the direction of Swift. >> When writing your review, here are some questions you might wan

Re: [swift-evolution] renaming CustomStringConvertible

As I understand things, the point of the whole “Syntax.Literal.ICan’tRememberWhatIt’sCalledToday” discussion was that syntactically speaking, literals kinda work the opposite as how everyone thinks they do. That’s not the case here; CustomStringConvertible clearly only requires `var description

Re: [swift-evolution] [Proposal] Sealed classes by default

I almost sent out an email with what you wrote. how about `public( nonfinal )` > - use “public(nonfinal)” to mean “exported out of the module, > subclass/overridable” I think just `open` would be a little bit better. `public( open )` > On Jul 1, 2016, at 11:20 AM, Sean Heber via swift-evolu

Re: [swift-evolution] [Proposal] Union Type

Sent from my iPad > On Jul 1, 2016, at 1:59 PM, David Sweeris via swift-evolution > wrote: > > It’s already on that list. That’s what Joe was quoting from earlier. > > Everybody (I hope) understands the “something the type system cannot […] > support” part, but if the “should not” bit were

Re: [swift-evolution] renaming CustomStringConvertible

On Fri, Jul 1, 2016 at 12:48 PM, Vladimir.S wrote: > On 01.07.2016 22:22, Dmitri Gribenko via swift-evolution wrote: >> >> On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution >> wrote: >>> >>> >>> To the Swift community, >>> >>> May I put forth a couple of new names for the follo

[swift-evolution] [Discussion] Rename BitwiseOperations protocol

Hi all, This is probably very minor, but I’m not sure the protocol name “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what the guidelines have to say about protocol names: Protocols that describe what something is should read as nouns (e.g. Collection). Protocols that descr

Re: [swift-evolution] renaming CustomStringConvertible

On 01.07.2016 22:22, Dmitri Gribenko via swift-evolution wrote: On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution wrote: To the Swift community, May I put forth a couple of new names for the following protocol: - CustomStringConvertible — rename as ‘Descriptive’ or as

Re: [swift-evolution] renaming CustomStringConvertible

How do you mean? On Fri, Jul 1, 2016 at 14:44 David Sweeris wrote: > Maybe... It's just a property, though. I *think* if something's moving > into the Syntax thing, I'd rather look for a way to move string > interpolation there. Maybe. > > - Dave Sweeris > > On Jul 1, 2016, at 14:24, Xiaodi Wu vi

Re: [swift-evolution] renaming CustomStringConvertible

Maybe... It's just a property, though. I think if something's moving into the Syntax thing, I'd rather look for a way to move string interpolation there. Maybe. - Dave Sweeris > On Jul 1, 2016, at 14:24, Xiaodi Wu via swift-evolution > wrote: > > Perhaps another candidate for sinking into `S

Re: [swift-evolution] renaming CustomStringConvertible

Perhaps another candidate for sinking into `Syntax`? On Fri, Jul 1, 2016 at 14:23 Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution > wrote: > > > > To the Swift community, > > > > May I put forth a coupl

Re: [swift-evolution] renaming CustomStringConvertible

On 01.07.2016 22:16, Eric Habberstad via swift-evolution wrote: To the Swift community, May I put forth a couple of new names for the following protocol: - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’ Strong +1 from me. It looks and reads nice, clearly shows the m

Re: [swift-evolution] renaming CustomStringConvertible

On Fri, Jul 1, 2016 at 12:16 PM, Eric Habberstad via swift-evolution wrote: > > To the Swift community, > > May I put forth a couple of new names for the following protocol: > > > - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’ > > > Two goals for Swift is clarity and joy

Re: [swift-evolution] renaming CustomStringConvertible

IIRC, "custom" was used because it's not just conforming types that are string convertible; it's that these types have a custom string conversion. I can appreciate how this is an important point to communicate. On Fri, Jul 1, 2016 at 14:16 Eric Habberstad via swift-evolution < swift-evolution@swift

[swift-evolution] renaming CustomStringConvertible

To the Swift community, May I put forth a couple of new names for the following protocol: - CustomStringConvertible — rename as ‘Descriptive’ or as ‘Revealable’ Two goals for Swift is clarity and joy in use of the language, so I strongly feel that ‘Custom-‘ not be part of any new name her

Re: [swift-evolution] [Proposal] Union Type

It’s already on that list. That’s what Joe was quoting from earlier. Everybody (I hope) understands the “something the type system cannot […] support” part, but if the “should not” bit were expanded a bit so that people would know why it shouldn’t be supported… The closest I ever saw to a reaso

  1   2   >