[swift-evolution] Support for newtype feature/typesafe calculations

Hello, newcomer here. The other day I was reading about https://www.reddit.com/r/swift/comments/3zbk64/type_math/ and given the verbose solutions decided to pitch a possible language improvement. But after reading through the archives it seems that this idea has already been pitched before: *

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution > wrote: > > I once suggested the following ternary like switch: > > let x = color ? > case .Red: 0xFF > case .Green: 0x00FF00 > case .Blue: 0xFF > default:

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 10:51 AM, Sean Heber wrote: > >>> And maybe allow a special case for boolean where you can leave off the >>> “case true:” part: >>> >>> let x = something ? thing() else: otherThing() >>> >>> And then you could more or less replace ternary with this new

Re: [swift-evolution] Support for newtype feature/typesafe calculations

I’m not saying your proposal would not be useful, but in the case of all of your examples, there are solutions that can be implemented now that might be better than just creating a new-type-but-exactly-the-same. > On 5 Jan 2016, at 16:11, Grzegorz Adam Hankiewicz via swift-evolution >

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

Hey Vincent, good proposal, love to see this in production. Better collection search would become quite handy :-) regards, Flori On Mon, Jan 4, 2016 at 4:13 PM, Vincent Esche via swift-evolution < swift-evolution@swift.org> wrote: > After having had this code laying around on my Mac since

Re: [swift-evolution] ternary operator ?: suggestion

>> And maybe allow a special case for boolean where you can leave off the “case >> true:” part: >> >> let x = something ? thing() else: otherThing() >> >> And then you could more or less replace ternary with this new construct that >> can do even more while looking very similar and still being

Re: [swift-evolution] [swift-users] Very strange automatic behavior between StringLiteralConvertible and pattern matching

Sorry about the double post. > On 05 Jan 2016, at 18:26, David Hart via swift-users > wrote: > > How is it that Swift allows code like this: > > struct Sneaky: StringLiteralConvertible { > init(stringLiteral value: String) {} >

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

Everyone, The sticking point here is that xcode generates the first syntax automatically. Simply filing a radar about this would be useless, so I believe the original proposal is meant to sort-of "light a fire" under the Xcode team; by introducing a new language feature they would be forced to

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 10:23 AM, Sean Heber wrote: > > >> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution >> wrote: >> >> I once suggested the following ternary like switch: >> >> let x = color ? >>case .Red: 0xFF >>

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Extensions on classes already work and I can't see them requiring @objc or @nonobjc. It's extensions on protocols that don't work from Objective-C. The way I understand it, Doug suggests a warning/error for extensions on @objc protocols, and a @nonobjc attribute to shut it up. Your point may

Re: [swift-evolution] Support for newtype feature/typesafe calculations

> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via swift-evolution > : > > The ideal would be for the compiler to pretend Euros or RefTablePk are > different types, yet use their parent type at the binary level. This needs a > specific syntax to teach the

Re: [swift-evolution] Failable Initializer Suggestion

My initial stance several months ago was that initializers should throw instead of returning nil, but I've changed it as a result of the error handling rationale (same document as Chris linked). Specifically this section, taken from ErrorHandlingRationale.rst: Simple domain errors A simple

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

> On Jan 4, 2016, at 5:39 PM, Kevin Ballard wrote: > > On Mon, Jan 4, 2016, at 03:22 PM, Paul Cantrell wrote: >> >> The bottom line is that not every NSString → String bridge need to be O(n). >> At least in theory. Someone with more intimate knowledge of NSString can >>

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 11:05 AM, Thorsten Seitz wrote: > >> >> Am 05.01.2016 um 17:29 schrieb Matthew Johnson : >> >> >>> On Jan 5, 2016, at 10:23 AM, Sean Heber wrote: >>> >>> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz

Re: [swift-evolution] ternary operator ?: suggestion

> Am 05.01.2016 um 16:23 schrieb Matthew Johnson > >> On Jan 5, 2016, at 9:12 AM, Craig Cruden wrote: >> >> Is there a reason why we are reusing “?” since the proposal is to leave >> ternary ? : as is. And “?” is also used by optionals. Why

Re: [swift-evolution] Support for newtype feature/typesafe calculations

> On Jan 5, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 05.01.2016 um 17:11 schrieb Grzegorz Adam Hankiewicz via swift-evolution >> : >> >> The ideal would be for the compiler to pretend Euros or RefTablePk

Re: [swift-evolution] ternary operator ?: suggestion

While it is real nice what can be done with a library solution, the switch-expression allows more than just comparing with a value. Library solutions won't be able to achieve the following features: - pattern matching - where clauses - exhaustiveness check -Thorsten > Am 05.01.2016 um 18:10

[swift-evolution] Thoughts on clarity of Double and Float type names?

Hi all, I'm curious how other members of the Swift community feel about the clarity of the "Double" and "Float" type names. It seems incongruous that the default type for integers is "Int", but the default type for floating point numbers is not "Float". What if the name "Float" were given to the

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

> I’d also like to hear more thoughts on Kevin’s proposal from a broader range > of people. Derp, I mean Brent’s proposal. My brain is utterly unable to keep people’s names straight. Is there a clinical name for it? Because whatever it is, I’ve got it baaad. Brent and Kevin, apologies! P

Re: [swift-evolution] Support for newtype feature/typesafe calculations

Thanks for doing the work to collect links related to this topic! I am planning to give them a read. You may be interested in the proposal I am working on for automatic protocol forwarding. The first draft was posted to the list last week:

[swift-evolution] Very unexpected automatic behaviour between StringLiteralConvertible and pattern matching!

How is it that Swift allows code like this: struct Sneaky: StringLiteralConvertible { init(stringLiteral value: String) {} init(extendedGraphemeClusterLiteral value: String) {} init(unicodeScalarLiteral value: String) {} } func ~=(sneaky: Sneaky, string: String) -> Bool {

Re: [swift-evolution] Default lazy constructor

Have you heard of the property behaviors proposal? Félix > Le 5 janv. 2016 à 08:48:03, James Campbell via swift-evolution > a écrit : > > When creating a lazy variable, maybe we should allow for default closures, i.e > > lazy var userSession: UserSession > > Which

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 3:51 AM, Andrey Tarantsov wrote: > > I'm against this, because I often write extensions on Apple classes (like, > say, UIColor) that are only intended to be used from Swift, in a pure-Swift > project, and I need no stinking' @nonobjc in there. You

Re: [swift-evolution] Customized Inline Init Closure

Very nice! I also think that using $0 is fine as it avoids all the problems with shadowing the outer self and thereby avoids erros and increases readability. -Thorsten > Am 04.01.2016 um 18:51 schrieb Jo Albright via swift-evolution > : > > Here is another option.

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution > wrote: > > There is no direct way to implement Objective-C entry points for protocol > extensions. One would effectively have to install a category on every > Objective-C root class [*] with the

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz wrote: > > I once suggested the following ternary like switch: > > let x = color ? > case .Red: 0xFF > case .Green: 0x00FF00 > case .Blue: 0xFF > default: 0xFF This is the

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 4, 2016, at 11:31 PM, Howard Lovatt wrote: > > I was guessing that the current proposal does not change anything re. default > and current member wise initializers and so in addition to suggesting Scala > syntax I was also suggesting the transformation shown,

Re: [swift-evolution] Testing Assertions

It is true that testing an assert is not really possible, as it basically crashes the app. But we have to take into account that the behaviour of the assert method is not strait-forward : it depends on what is the optimisation level. Here is an extract of the inline doc of the assert method :

[swift-evolution] Default lazy constructor

When creating a lazy variable, maybe we should allow for default closures, i.e lazy var userSession: UserSession Which will construct that object for you instead of having to do: lazy var object: MyObject { let userSession = UserSession() return userSession }() If the

Re: [swift-evolution] ternary operator ?: suggestion

Is there a reason why we are reusing “?” since the proposal is to leave ternary ? : as is. And “?” is also used by optionals. Why not just use a new keyword like “match” (which I prefer better than which - but that may be because it is familiar to me :p ). then reuse the rest of switch

Re: [swift-evolution] ternary operator ?: suggestion

Sent from my iPad > On Jan 5, 2016, at 9:12 AM, Craig Cruden wrote: > > Is there a reason why we are reusing “?” since the proposal is to leave > ternary ? : as is. And “?” is also used by optionals. Why not just use a > new keyword like “match” (which I prefer

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

Yes. All of these variants are covered in the book The Swift Programming Language in some detail. Alex – Alexander Kempgen a...@kempgen.de > Am 05.01.2016 um 14:42 schrieb James Campbell via swift-evolution > : > > So the [Int]() is shorthand for Array() > >

Re: [swift-evolution] ternary operator ?: suggestion

I once suggested the following ternary like switch: let x = color ? case .Red: 0xFF case .Green: 0x00FF00 case .Blue: 0xFF default: 0xFF Reusing "case" and "default" makes it possible IMO to distinguish the cases even if writing them in one line

Re: [swift-evolution] ternary operator ?: suggestion

In addition to the problems that you already cited, a library could not check exhaustiveness and we would lose pattern matching. -Thorsten > Am 05.01.2016 um 00:53 schrieb Paul Ossenbruggen via swift-evolution > : > > Just tried going down this path a bit of

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

> On 5 Jan 2016, at 13:42, James Campbell wrote: > > So the [Int]() is shorthand for Array() Yes. In general, you can write [T] anywhere you can write Array and [U : V] anywhere you can write Dictionary. The are both syntactic sugar. > > On Tue, Jan 5, 2016 at

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> The “type parameter list” syntax is sugar that could be implemented as a > layer on top of the current proposal or could be implemented orthogonally. Hi Howard, I've heard this argument before, so I'll repeat my answer as well: Both offers don't make sense, it's either one way or the other (or

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:37 PM, Marcelo Alves via swift-evolution > wrote: > > >> On Jan 5, 2016, at 16:06, Thorsten Seitz via swift-evolution >> > wrote: >> >> >>> Am 05.01.2016 um 18:12 schrieb Matthew

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

> On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution > wrote: > > Everyone, > > The sticking point here is that xcode generates the first syntax > automatically. > > Simply filing a radar about this would be useless, so I believe the original >

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

A few requests for clarification from the proposal authors: 1. The proposal talks in several places about “test modules” (for example, “test-module is created per subdirectory of Tests”). How do these test modules interact with Package.swift? Does each of them have a separate target? If so,

Re: [swift-evolution] ternary operator ?: suggestion

> Am 05.01.2016 um 18:12 schrieb Matthew Johnson : > > On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution > > wrote: > > I once suggested the following ternary like switch: >

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> That said, personally, my feeling is that the momentum here in the broad > family of C languages (including things like Java) is very strong, and that > diverging from that would be extremely problematic. I don’t see any “active" > problems with our current names. If this is a matter of

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 5:41 AM, Charles Srstka wrote: > >> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> There is no direct way to implement Objective-C entry points for

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

+1. I think it brings a nice symmetry with the integer types and puts size classing in a more consistent place. And to be frank, I already typedef the intrinsic float/double types in my C code to f32/f64 for similar reasons. -David > On Jan 4, 2016, at 12:58 PM, Alex Johnson via

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On Jan 4, 2016, at 12:58 PM, Alex Johnson via swift-evolution wrote: > Hi all, > > I'm curious how other members of the Swift community feel about the clarity > of the "Double" and "Float" type names. It seems incongruous that the default > type for integers is

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 12:06 PM, Thorsten Seitz wrote: > > >> Am 05.01.2016 um 18:12 schrieb Matthew Johnson > >: >> >> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution >>

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Jan 5, 2016, at 12:12 PM, Tino Heth <2...@gmx.de> wrote: > > >> The “type parameter list” syntax is sugar that could be implemented as a >> layer on top of the current proposal or could be implemented orthogonally. > Hi Howard, > I've heard this argument before, so I'll repeat my answer

Re: [swift-evolution] ternary operator ?: suggestion

> On Jan 5, 2016, at 16:06, Thorsten Seitz via swift-evolution > wrote: > > >> Am 05.01.2016 um 18:12 schrieb Matthew Johnson > >: >> >> On Jan 5, 2016, at 12:29 AM, Thorsten Seitz via swift-evolution

[swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

Hello Swift community, The review of “Swift Testing” for the Package Manager begins now and runs through Thursday, January 7th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md For this particular review,

Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

On Tue, Jan 5, 2016, at 10:47 AM, Chris Lattner via swift-evolution wrote: > > > On Jan 5, 2016, at 8:07 AM, Dennis Lysenko via swift-evolution > > wrote: > > > > Everyone, > > > > The sticking point here is that xcode generates the first syntax > > automatically.

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

> On Jan 6, 2016, at 4:06 AM, Rick Ballard via swift-evolution > wrote: > > * What is your evaluation of the proposal? Overall this is great direction, but needs more deliberation and sifting about the details. This kind of infrastructure will live a while, or

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I stand corrected. Félix > Le 5 janv. 2016 à 22:19:28, Charles Srstka a écrit > : > >> On Jan 5, 2016, at 9:06 PM, Félix Cloutier > > wrote: >> >> The linker is smart enough to get rid of frameworks that you don't

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 9:06 PM, Félix Cloutier wrote: > > The linker is smart enough to get rid of frameworks that you don't actually > use. > > Félix objc_copyClassList leaves a value of 14694 in classCount. When I just link against Foundation it only gives 1581. otool

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

Wow! I didn't know that worked. It's a bit surprising, and perhaps not intended. I think the proposal is still valid. On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers wrote: > You can shadow self with a guard like you wrote it if use the keyword > escaping backquotes

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> This has been suggested before, usually in the form of a separate `implement` keyword. The main problem is that it makes it impossible to write a protocol after the fact which formalizes some existing pattern in the types. I think this is a great point and would be a con that I hadn't

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

> As an OS X and iOS developer, it sometimes seems that I work with > [GG|NS]Point, [GG|NS]Rect, and [GG|NS]Size almost as much as I use Float or > String. I’d love to see Swift’s standard library include Rect, Point, and > Size types, with bridging to make them “just work” with any UIKit or

Re: [swift-evolution] ternary operator ?: suggestion

Heh, one other thought. Pretty sure this was rejected by the switch statement but if keeping it concise for expressions is a goal then _ might make sense for the default case especially with this form. :-) let fh = ?(color, .Red: 0xFF // only one expression can be the result here so case

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

I actually expected it to create a different identifier that is unrelated to the keyword, so you can refer to `self` with backticks in the future to get the version bound by the guard, and self as a keyword to get the original value of self. Not that I think this is particularly useful, of

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 8:29 PM, Greg Parker wrote: > >> >> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor >>

[swift-evolution] [Accepted] SE-0014 Constraining `AnySequence.init`

The review of SE-0014 "Constraining `AnySequence.init`" ran from December 18–21, 2015. The proposal has been accepted for Swift 2.2. https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md Thank you to everyone who participated in the review

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> What is your evaluation of the proposal? +1 for changing the name, but -1 for "associatedtype" in particular. Alternate suggestions: - associatedType Element - associated_type Element - associated type Element - associated Element - type Element - having Element > Is the

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

The linker is smart enough to get rid of frameworks that you don't actually use. Félix > Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution > a écrit : > >> On Jan 5, 2016, at 8:29 PM, Greg Parker > > wrote:

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

Does further use of self after that actually use a strong shadowing variable? Or does it go back to the weak reference it already had as if the shadow were not there? > On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > Wow! I didn't

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

NSRect and CGRect are already the same type and can be used interchangeably: > typedef CGRect NSRect; You can easily typealias CGRect to Rect as well if you don't like the two-letter prefix. Otherwise, if you can wait a bit, SE-0005

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> Am 06.01.2016 um 06:23 schrieb Xiaodi Wu via swift-evolution > : > > It would remain very much possible to formalize an existing pattern because, > in the case of your example (unless I'm misunderstanding?), you are not also > providing a default implementation of

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

You can shadow self with a guard like you wrote it if use the keyword escaping backquotes like so: guard let `self` = self else { return } On Wed, Jan 6, 2016 at 10:55 AM Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > FWIW, in a codebase of ~150 Swift files, I see

Re: [swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

> Taking inspiration from syntax used for methods in classes that override > methods in superclasses, require methods that override dynamically dispatched > default implementations in protocol extensions to use the override keyword. > Likewise, forbid the override keyword if the method being

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

+1 Type narrowing would also fit nicely with union types (as demonstrated in Ceylon). -Thorsten > Am 05.01.2016 um 23:37 schrieb Dennis Lysenko : > > That said, I am in favor of automatic type narrowing. As long as it doesn't > complicate the compiler

[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

The review of SE-0009 "Require self for accessing instance members`" ran from December 16–20, 2015. The proposal has been rejected. https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

Thorsten, Not that I disapprove (Kotlin does the same and it's great), the precedent seems to have already been set in people's minds that there won't be any kind of implicit type narrowing and I predict a fair few will respond with "You can already do that with optional binding, and I'm

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

>> Yes, and indeed, this isn’t really acceptable, but I think any changes to >> how this work would involve a discussion on the swift-build-dev mailing >> list. Really how targets depend on each other and external dependencies in >> the Package.swift manifest needs some work in general. > >

Re: [swift-evolution] API Guideline bugs and enhancements

Great discussion, thanks Erika for bringing this up. Chiming in with a little question here. The API guidelines say: > Boolean methods and properties should read as assertions about the receiver I know the document is about APIs but is this also recommended for local variables and constants?

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

Thats a small but huge improvement :) On Tue, Jan 5, 2016 at 6:58 PM, Chris Lattner wrote: > You’re completely right, but we don’t need to change the swift language to > fix that. As of 3f19714, which I just pushed, we now emit this error > message (which includes a fixit

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

> On Jan 5, 2016, at 12:21 PM, Paul Cantrell wrote: > > Thanks for the clarifications. This helps me understand much better how the > proposal plays out. > >> On Jan 5, 2016, at 2:14 PM, Max Howell wrote: >> >>> 1. The proposal talks in several

Re: [swift-evolution] [Proposal]: Drastically improve searching API (indexOf(…)) of CollectionType

Fair point! I’m all in favor of a simple(r) API. Noted, and thanks for the comment! > On 05 Jan 2016, at 03:07, Donnacha Oisín Kidney > wrote: > > Unless I’m confused, all of the “ranged” overloads can already be achieved by > composing ranged subscripts with the

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm on the fence here, I think it's a good solution if a project has ongoing objc dependencies. However I have a few issues/suggestions: 1) If a project is iteratively migrating from objc to swift, as I'm sure many are (a large project I'm working on included), then it would make that job much

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm against this, because I often write extensions on Apple classes (like, say, UIColor) that are only intended to be used from Swift, in a pure-Swift project, and I need no stinking' @nonobjc in there. How much of a problem can this surprise be? You call a method, the compiler tells you it's

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

In principle, having Float, Float32, and Float64 and no “Double” at all seems highly sensible to me. In practice, the migration cost of changing the meaning of Float from “32-bit” to “platform preferred size” seems like a potential deal-killer. P > On Jan 5, 2016, at 2:25 PM, Alex Johnson via

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

>>> That said, personally, my feeling is that the momentum here in the broad >>> family of C languages (including things like Java) is very strong, and that >>> diverging from that would be extremely problematic. I don’t see any >>> “active" problems with our current names. If this is a

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

What would this actually gain, other than most floating-point code producing different results even for basic arithmetic when run on differing platforms? Having “Int” mean “native word size” is tolerable because: (a) most integer code deals with small numbers for which the result is the same

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

> On Jan 5, 2016, at 2:32 PM, Max Howell wrote: > >> On Jan 5, 2016, at 12:21 PM, Paul Cantrell wrote: >> >>> On Jan 5, 2016, at 2:14 PM, Max Howell wrote: >>> 1. The proposal talks in several places about “test modules”

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

Overall, I think the feature is important to have, but I don’t understand some of the aspects of the proposal. I also don’t think there is a real focus for clarity on the types of testing that are being supported here. The implication is that unit tests are what this is being targeted, but is

Re: [swift-evolution] Custom summary for Mirrors?

Hi Joe, I respect the choice of the team to use Custom[Debug]StringConvertible in lieu of summary. At the same time, in my opinion the output of dump() has become significantly more difficult to read (c.f. unit tests in https://github.com/apple/swift/pull/838/files). Would you and the team be

Re: [swift-evolution] Custom summary for Mirrors?

> On Jan 5, 2016, at 5:28 PM, Austin Zheng via swift-evolution > wrote: > > Hi Joe, > > I respect the choice of the team to use Custom[Debug]StringConvertible in > lieu of summary. At the same time, in my opinion the output of dump() has > become significantly

Re: [swift-evolution] Beef up Imports

I like the fact that this would retain simplicity for basic uses - developers could continue to use 'import Mod' and not even know about the more advanced syntax unless they need that power. The additional syntax seems like a natural progression from the base case. Kevin, I understand the

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

This has come up before, in a thread called "Proposal: weakStrong self in completion handler closures". I'm still not 100% happy with the syntax, but I like that "guard let" can handle non-Void non-Optional returns well, while 'weakStrong' cannot. Jordan > On Jan 5, 2016, at 16:02, Hoon H.

Re: [swift-evolution] Proposal: Add SequenceType.first

On Tue, Jan 5, 2016, at 03:43 PM, Jordan Rose wrote: > >> On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution > evolut...@swift.org> wrote: >> >>> >>> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution >> evolut...@swift.org> wrote: >>> >>> On Sat, Jan 2, 2016, at 11:17 PM,

Re: [swift-evolution] Proposal: Add public(objc) modifier

Code completion aside, it just makes me really unhappy to expose a Swift API that nobody should *ever* call from Swift. I just don't want to have that API be accessible at all when it only exists to serve as the Obj-C entrypoint. -Kevin Ballard On Tue, Jan 5, 2016, at 02:55 PM, Félix Cloutier

Re: [swift-evolution] Custom summary for Mirrors?

Getting custom summaries for the common CG types certainly seems reasonable. We'd have to get approval from the appropriate teams at Apple, but I can't see any objections. Jordan > On Dec 30, 2015, at 9:55, Joe Groff via swift-evolution > wrote: > > I believe

Re: [swift-evolution] Beef up Imports

I'm (personally) not such a fan of saying "import just this one thing" or "import everything except this one thing"—you end up trying to use UIImage(named:), and then realizing you haven't imported any of the top-level names. But "import qualified" seems great to me, and "import Foo as Bar"

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Jan 2, 2016, at 23:53, Dave Abrahams via swift-evolution > wrote: > >> >> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution >> wrote: >> >> On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote: `buffered` is

Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

> On Jan 5, 2016, at 4:48 PM, Max Howell wrote: > >>> Yes, and indeed, this isn’t really acceptable, but I think any changes to >>> how this work would involve a discussion on the swift-build-dev mailing >>> list. Really how targets depend on each other and external

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

Perhaps instead of "auto" we could allow "lazy" to create a default lazy constructor for these cases ? On Tue, Jan 5, 2016 at 12:39 PM, James Campbell wrote: > See this code: > > var distanceCache: [Int: Int] = Dictionary() > It is very long and tedious to write

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

I don’t understand what the problem is > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution > wrote: > > See this code: > var distanceCache: [Int: Int] = Dictionary() > > It is very long and tedious to write especially if what I am storing

[swift-evolution] Be able to initialise empty dict with array constrcutor

See this code: var distanceCache: [Int: Int] = Dictionary() It is very long and tedious to write especially if what I am storing changes. I propose we be allowed to do the following: *var distanceCache: [Int: Int] = []* If this isn't possible then I wouldn't mind having some way of

Re: [swift-evolution] Be able to initialise empty dict with array constrcutor

The problem for me is that is so counter intuitive I didn't even know you could do that. On Tue, Jan 5, 2016 at 12:50 PM, Jeremy Pereira < jeremy.j.pere...@googlemail.com> wrote: > I don’t understand what the problem is > > > On 5 Jan 2016, at 12:39, James Campbell via swift-evolution < >

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

+1. Merely using "self?.something" repeatedly might produce unexpected behavior, if self becomes nil between calls. As I mentioned in another thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak). In many cases, I use the pattern somethingAsync { [weak self] in

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let strongSelf = self", and 26 occurrences of "self?." (which should arguably be changed to the former). Jacob On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch wrote: > +1. > > Merely using

Re: [swift-evolution] Custom summary for Mirrors?

Here are a couple of examples I had in mind. * Arrays (from test/1_stdlib/Runtime.swift:1348), dumping an array with 5 elements: BEFORE: ▿ 5 elements - [0]: a.MultiPayloadTagBitsSmallNonGenericEnumWithDefaultMirror.MacWrite - [1]:

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On Jan 5, 2016, at 4:41 PM, Janosch Hildebrand via swift-evolution > wrote: > > I also think that Float and Double are not ideal type names but I also agree > with many of the concerns that have been raised. > > > Why not simply use (the existing) Float32 and

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution > wrote: > >> On Jan 5, 2016, at 11:52 AM, Douglas Gregor > > wrote: >> >> There are better mechanisms for this than +load. But one would have to deal >>

  1   2   >