Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 24, 2016, at 9:43 PM, Chris Lattner wrote: > On Mar 24, 2016, at 7:28 PM, John McCall via swift-evolution > wrote: >> I'd actually be much more concerned about the pervasive assumptions about >> pointer representation in Clang and LLVM than I would be with Swift. >> >> Now, it would p

Re: [swift-evolution] Promote "primitive" types to enums in extensions

Why can’t you do this? No raw values required, except to initialize the enums. struct Card { enum Suit : Int { case Hearts, Spades, Diamonds, Clubs } enum Rank : Int { case Ace, Two, Three, Four, Five, Six, Seven, Eight, Nine, Jack, Queen, King } let suit : Suit let rank : Rank

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 24, 2016, at 6:02 AM, John Siracusa via swift-evolution wrote: > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 24, 2016, at 4:02 AM, Dany St-Amant via swift-evolution wrote: >> What do you all think? > > The think I fear with moduleprivate and fileprivate, is that someone will one > day suggest to lowerCamelCase them. The parenthesized version was de-facto > preventing my fear from ever being re

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

Okay, great. That makes sense, thanks for clarifying Chris. -Colin (via thumbs) > On Mar 25, 2016, at 12:35 AM, Chris Lattner wrote: > > >> On Mar 24, 2016, at 11:09 AM, Colin Barrett via swift-evolution >> wrote: >> >> The proposal is unclear to me in what it is, er, proposing. The motiva

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

On Mar 24, 2016, at 7:28 PM, John McCall via swift-evolution wrote: > I'd actually be much more concerned about the pervasive assumptions about > pointer representation in Clang and LLVM than I would be with Swift. > > Now, it would probably be very annoying to support a platform where differen

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

> On Mar 22, 2016, at 2:35 PM, Chris Lattner wrote: > > The review of "Adding initializers to Int and UInt to convert from > UnsafePointer and UnsafeMutablePointer" begins now and runs through March > 25th. The proposal is available here: > > > https://github.com/apple/swift-evolution/

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

> On Mar 24, 2016, at 11:09 AM, Colin Barrett via swift-evolution > wrote: > > The proposal is unclear to me in what it is, er, proposing. The motivation > section speaks about allow `let` to be used as argument label, but the > proposed solution says that func foo(let x: Int) { … } would be

Re: [swift-evolution] Feature proposal: Range operator with step

On Thu, Mar 24, 2016 at 4:18 PM, Dave Abrahams via swift-evolution wrote: > > on Wed Mar 23 2016, Xiaodi Wu wrote: > >> So, in other words, you'd be satisfied with the following addition to >> the standard library? >> >> ``` >> extension Range where Element: Strideable { >> func by(step: Elem

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

> On Mar 24, 2016, at 1:26 PM, Chris Lattner wrote: > > >> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote >>> All

Re: [swift-evolution] SetAlgebra naming update

On Thu, Mar 24, 2016 at 7:23 PM, Dave Abrahams via swift-evolution wrote: > > on Thu Mar 24 2016, Xiaodi Wu wrote: > >> Much improved, IMO. A few thoughts: >> * typo in "formSymmetricDifference" > > Thanks, fixed. > >> * I don't know about the preposition "from" in "form symmetric difference >> f

Re: [swift-evolution] SetAlgebra naming update

> On Mar 24, 2016, at 7:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Mar 24 2016, Ricardo Parada wrote: > >> Hi all, >> >> I could get used to the formNoun naming convention for the mutable versions >> of the methods. >> >> I would suggest the following changes: >> >>

Re: [swift-evolution] Binding generic types using a metatype parameter

> On Mar 24, 2016, at 4:04 PM, Joanna Carter > wrote: > > Unfortunately, this doesn't compile… > > extension PropertyType > { > private static func create() -> Property > { >return Property.init() >^ '>' is no

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 24, 2016, at 3:50 PM, Brent Royal-Gordon via swift-evolution > wrote: >> Thirdly, as mentioned in the prior discussion it's certainly possible on >> some platforms to remap the memory page at address 0x0 and make it usable to >> userland code. Even if we don't currently support any suc

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> * What is your evaluation of the proposal? +1. This is a very nice improvement for code that needs to work directly with pointers. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and

[swift-evolution] NSCoding-like Persistence

What is the current plan for persisting things like enums and structs in Swift? After the POP talk at WWDC, I excitedly rewrote many of my frameworks to use protocols and structs/enums instead of NSObject subclasses. For the most part, this has been fantastic… most things are much more powerfu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

> What is your evaluation of the proposal? Big +1. I would prefer to see it go further to allow arbitrary constraints, but it is a big step forward and that can come in the future. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes > Does this proposal fit

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

on Thu Mar 24 2016, Andrey Tarantsov wrote: >>> The new default is better for: >>> >>> - (A) classes that provide both mutating and non-mutating methods; >>> - (B) methods where forgetting to use the result produces a bug (a >>> download task that needs to be resumed, an alert that needs to be

Re: [swift-evolution] Feature proposal: Range operator with step

> That > would imply that floating types should not conform to Strideable, > which raises the question of whether Strideable should be folded into > the Integer protocol. Personally, I get a lot of mileage out of conforming NSDate to Strideable. (Although obviously it ought to be using a float

Re: [swift-evolution] SetAlgebra naming update

> On Mar 24, 2016, at 6:19 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Mar 24 2016, Erica Sadun wrote: > >>> >>> On Mar 24, 2016, at 2:39 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> Just an update: >> >>> >>> The naming guidelines working group went ba

Re: [swift-evolution] Bike-shedding alternate collections API

on Thu Mar 24 2016, Howard Lovatt wrote: > Detailed comments about iterator inline below. > > Big picture is: > > Separating lazy collections from eager collection with a view to a future > world with lazy parallel collections. > Returning AnyXxx rather than a specific type to both keep types s

Re: [swift-evolution] SetAlgebra naming update

on Thu Mar 24 2016, Ricardo Parada wrote: > Hi all, > > I could get used to the formNoun naming convention for the mutable versions > of the methods. > > I would suggest the following changes: > > Remove the parameter label from symmetricDifference() and > formSymmetricDifference() to be cons

Re: [swift-evolution] SetAlgebra naming update

on Thu Mar 24 2016, Erica Sadun wrote: >> >> On Mar 24, 2016, at 2:39 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> Just an update: > >> >> The naming guidelines working group went back into negotiation over >> the shape of SetAlgebra (and thus, Set and OptionSet) for >> Swift 3

Re: [swift-evolution] SetAlgebra naming update

on Thu Mar 24 2016, Xiaodi Wu wrote: > Much improved, IMO. A few thoughts: > * typo in "formSymmetricDifference" Thanks, fixed. > * I don't know about the preposition "from" in "form symmetric difference > from" (also, inconsistent, because you don't have "form union with") Good point. What

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

on Thu Mar 24 2016, Howard Lovatt wrote: > Not sure what you are saying? > > for index in empty.indices { > // never executed > } > > Would still work. Not every algorithm is based on a linear traversal (e.g. binary search, sort, etc.) For those you really need to access star

Re: [swift-evolution] [Proposal] Factory Initializers

Comments inline. > On Mar 24, 2016, at 12:10 AM, Riley Testut wrote: > > While I do believe your proposed additions have their benefits, my gut tells > me this is too large a change to Swift for an arguably small gain. For this > proposal, I'm wanting to keep the change as minimalistic as poss

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

+1 for adding Java behaviour, it is something I have missed. The example would be: enum Suit: Int, CustomStringConvertible { case Hearts { var description: String { return “♥️" } } case Spades { var description: String { return “♠️" } } cas

Re: [swift-evolution] Binding generic types using a metatype parameter

Of course, after all this effort, I still have the problem of how to get the Any.Type from the SubjectType property of a Mirror into a PropertyType.Type. What would really make life easier here would be the ability to extend Any. Any chance? Joanna -- Joanna Carter Carter Consulting _

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

+1 for reasons already mentioned by others. On Thu, Mar 24, 2016 at 5:54 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0048 "Generic Type Aliases" begins now and runs through > March 29, 2016. The proposal is available her

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

Strong +1 here too. R+ Sent from my iPhone > On 24 Mar 2016, at 17:54, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0048 "Generic Type Aliases" begins now and runs through > March 29, 2016. The proposal is available here: > > https://github.com/apple/swift-evolution

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon > wrote: > >> I think it does. `module` could mean many things related to how Swift >> creates and consumes modules. >> `moduleprivate` combines something about access levels (public/private) and >> scope (module), is easy to >> Google, offe

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> I think it does. `module` could mean many things related to how Swift creates > and consumes modules. > `moduleprivate` combines something about access levels (public/private) and > scope (module), is easy to > Google, offers few "wrong" interpretations. By using a longer keyword, it is > le

Re: [swift-evolution] Binding generic types using a metatype parameter

Hi Joe > Sorry for not getting back to you sooner. Hey, I'm guessing you're busier than I am ;-) > What's necessary here is a way to "open" the type of Any.Type, turning it > back into something the compiler considers as a type instead of a value. Yes, that's what I had in mind > This is some

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> * What is your evaluation of the proposal? I'm in favor. The ability of UnsafePointer to represent nil pointers has always been an odd duck, introducing an unmarked (and undocumented!) implicit trap in `memory` (now `pointee`), preventing the use of Optional constructs, and making Swift

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

Hi Alex (and all other note-takers), these notes are helpful and really appreciated. Thanks for making them available. :) Daniel. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolut

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> Thirdly, as mentioned in the prior discussion it's certainly possible on some > platforms to remap the memory page at address 0x0 and make it usable to > userland code. Even if we don't currently support any such platforms, we > shouldn't lock ourselves into a situation where we need to be abl

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

On Mar 24, 2016, at 6:10 PM, Brent Royal-Gordon via swift-evolution wrote: > Honestly, though, I'm not sure why people are working so hard to cram > `private` in there. Does `moduleprivate` or `private(module)` really convey > more information than `module`? Particularly once you've looked it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

> * What is your evaluation of the proposal? I'm in favor of the change, but not the proposal or review. This seems like a mere omission from SE-0003 "Removing var from Function Parameters" . I

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

On Mar 24, 2016, at 5:55 PM, Max Howell wrote: >> Thanks for sending out this proposal. I admit I’m somewhat ignorant of the >> current state of SwiftPM so feel free to point me at existing resources if >> I’m missing basic things. >> >> You don’t cover it in your proposal, but does this mea

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 24, 2016, at 4:10 PM, Brent Royal-Gordon via swift-evolution > wrote: > Honestly, though, I'm not sure why people are working so hard to cram > `private` in there. Does `moduleprivate` or `private(module)` really convey > more information than `module`? Particularly once you've looked

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Why is it important to highlight word boundaries in so many other conventions > in Swift but not in this one? What would be lost with this alternative? > > public > module_private > file_private > private > > Is it just the extra (chorded, on US keyboards) keystroke? I think the > readability

Re: [swift-evolution] Bike-shedding alternate collections API

Detailed comments about iterator inline below. Big picture is: Separating lazy collections from eager collection with a view to a future world with lazy parallel collections. Returning AnyXxx rather than a specific type to both keep types short and to be more flexible. Removing constraints on I

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> Why is it important to highlight word boundaries in so many other conventions > in Swift but not in this one? What would be lost with this alternative? > > public > module_private > file_private > private > > Is it just the extra (chorded, on US keyboards) keystroke? I think the > readability

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

> Thanks for sending out this proposal. I admit I’m somewhat ignorant of the > current state of SwiftPM so feel free to point me at existing resources if > I’m missing basic things. > > You don’t cover it in your proposal, but does this mean pkg-config is now a > dependency for SwiftPM? I may b

Re: [swift-evolution] SetAlgebra naming update

Hi all, I could get used to the formNoun naming convention for the mutable versions of the methods. I would suggest the following changes: Remove the parameter label from symmetricDifference() and formSymmetricDifference() to be consistent with the other methods. Consider renaming: subtrac

Re: [swift-evolution] [Idea] allValues for RawRepresentable enums

My bad, I didn't see the proposal listed in evolution and didn't think to check the pull requests. - Kevin Randrup On Thu, Mar 24, 2016 at 5:28 PM, Jacob Bandes-Storch wrote: > Please see existing discussion at > https://github.com/apple/swift-evolution/pull/114. > > As discussed on #199

Re: [swift-evolution] idea: immutable setters for structs and tuples?

> On Mar 24, 2016, at 3:39 PM, Brent Royal-Gordon > wrote: > >>> I think this is better modeled in Swift as something like: >>> >>> let john = (firstName:"John", lastName:"Doe") >>> let alice = with(john) { >>> $0.firstName = "Alice" >>> } >> >> You can kind of do this

Re: [swift-evolution] idea: immutable setters for structs and tuples?

>> I think this is better modeled in Swift as something like: >> >> let john = (firstName:"John", lastName:"Doe") >> let alice = with(john) { >> $0.firstName = "Alice" >> } > > You can kind of do this now: > > struct Person { > var firstName, lastName: String > }

Re: [swift-evolution] SetAlgebra naming update

Much improved, IMO. A few thoughts: * typo in "formSymmetricDifference" * I don't know about the preposition "from" in "form symmetric difference from" (also, inconsistent, because you don't have "form union with") * "form" is fine, but scans similarly to "from" when reading quickly On Thu, Mar 24

Re: [swift-evolution] Bike-shedding alternate collections API

on Thu Mar 24 2016, Howard Lovatt wrote: > ___ swift-evolution mailing list > swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/ > swift-evolution > > Bike-shedding alternate collections API - cut down to keep them short enough > to

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

>> The new default is better for: >> >> - (A) classes that provide both mutating and non-mutating methods; >> - (B) methods where forgetting to use the result produces a bug (a >> download task that needs to be resumed, an alert that needs to be >> displayed, a listener that needs to be stored som

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

> On Mar 24, 2016, at 6:00 PM, Chris Lattner wrote: > > The review of "Remove explicit use of let from Function Parameters" begins > now and runs through March 27th. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-fu

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

Not sure what you are saying? for index in empty.indices { // never executed } Would still work. On Friday, 25 March 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Mar 23 2016, Howard Lovatt > wrote: > > > +1 I think it is a good idea t

Re: [swift-evolution] Deprecating Trailing Closures

> I use trailing closures all the time because I find the brackets too noisy, > like ; at the end of a line is too noisy. The sort of code I use is: > > let foo = myArray > .filter { $0 & 1 == 1 } > .map { $0 + 1 } > .reduce(0) { $0 + $1 } +1 to this. Please don't re

Re: [swift-evolution] [Idea] allValues for RawRepresentable enums

Please see existing discussion at https://github.com/apple/swift-evolution/pull/114. As discussed on #199 , I believe we should continue discussing this (preferably on the same thread as the original, or a new one that references it), but I'm curr

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

on Wed Mar 23 2016, Howard Lovatt wrote: > +1 I think it is a good idea to make a collection run from firstIndex to > lastIndex inclusively (note name change to match firstElement and > lastElement). For an empty collection both firstIndex and lastIndex would > be invalid values that would cause

[swift-evolution] [Idea] allValues for RawRepresentable enums

# Summary Add an allValues function to all enums that are RawRepresentable to access, iterate over, and count all of the values of an enum. The usage is general enough that I believe it would be a great addition to the language. This can currently be "hacked" in a few different ways by using the R

Re: [swift-evolution] [Review] SE-0053 Remove explicit use of let from Function Parameters

> * What is your evaluation of the proposal? > Yes good idea it is spurious > * Is the problem being addressed significant enough to warrant a > change to Swift? > Marginal > * Does this proposal fit well with the feel and direction of Swift? > Yes, eliminate thing

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> * What is your evaluation of the proposal? > Good idea, much more logical > * Is the problem being addressed significant enough to warrant a > change to Swift? > Yes, it is an anomaly > * Does this proposal fit well with the feel and direction of Swift? > Yes, op

Re: [swift-evolution] Feature proposal: Range operator with step

on Wed Mar 23 2016, Xiaodi Wu wrote: > So, in other words, you'd be satisfied with the following addition to > the standard library? > > ``` > extension Range where Element: Strideable { > func by(step: Element.Stride) -> StrideTo { > return startIndex.stride(to: endIndex, by: step)

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

> On Mar 24, 2016, at 11:57 AM, Russ Bishop wrote: > > >> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution >> mailto:swift-evolution@swift.org>> wrote >> Allow Swift types to provide custom Objective-C representations >> >> https://github.com/apple/swift-evolution/pull/198 >>

Re: [swift-evolution] Deprecating Trailing Closures

I use trailing closures all the time because I find the brackets too noisy, like ; at the end of a line is too noisy. The sort of code I use is: let foo = myArray .filter { $0 & 1 == 1 } .map { $0 + 1 } .reduce(0) { $0 + $1 } On Friday, 25 March 2016, Haravikk via swif

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

on Wed Mar 23 2016, Andrey Tarantsov wrote: >> What is your evaluation of the proposal? > > -0.5 if the annotation is verbose (much longer than @discardable). > +0.5 if the annotation is pleasant and concise, like @discardable > >> Is the problem being addressed significant enough to warrant a c

Re: [swift-evolution] SetAlgebra naming update

> > On Mar 24, 2016, at 2:39 PM, Dave Abrahams via swift-evolution > wrote: > > > Just an update: > > The naming guidelines working group went back into negotiation over > the shape of SetAlgebra (and thus, Set and OptionSet) for > Swift 3, and reached a new consensus. We intend to bring for

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> * What is your evaluation of the proposal? Currently, I'm -0.8 on this, for a few reasons. Firstly, UnsafePointers are explicitly 'Unsafe' already. Making them more 'safe' could encourage more widespread usage of them, when in reality they're not necessary for 90% of cases. Secondly, we wil

Re: [swift-evolution] [proposal] Generic type aliases

on Wed Mar 16 2016, Joe Groff wrote: >> On Mar 16, 2016, at 5:02 PM, Chris Lattner wrote: >> >> On Mar 16, 2016, at 4:56 PM, Joe Groff > > wrote: We shouldn’t infer it the requirement. > Rationale: I see this as analogous (in two ways) to why we don’t i

Re: [swift-evolution] SetAlgebra naming update

I would suggest xxxing and xxx naming like sorting and sort, e.g.: y = x.unioning(z) x.union(z) The consistency of naming is more important to me than correct English. The reason for this preference is that it quickly becomes 2nd nature to know the names of variations and because the nam

Re: [swift-evolution] [Proposal] Add Binary Search functions to SequenceType

on Tue Mar 15 2016, Nate Cook wrote: >> On Mar 15, 2016, at 1:58 PM, Lorenzo Racca via swift-evolution >> wrote: >> >>> On Mar 15, 2016, at 6:49 PM, Haravikk >>> >> > > >>> wrote: >>> On 15 Mar 2016, at 15:48, Lorenzo Racca >>>

Re: [swift-evolution] [Proposal] Change guarantee for GeneratorType.next() to always return nil past end

on Thu Mar 17 2016, Kevin Ballard wrote: > On Wed, Mar 16, 2016, at 09:59 AM, Erica Sadun wrote: >> >>> On Mar 16, 2016, at 10:41 AM, Joe Groff wrote: >>> On Mar 16, 2016, at 8:24 AM, Erica Sadun via swift-evolution wrote: > On Mar 8, 2016, at 7:29 PM, Kevin Ballard v

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

> > > >- What is your evaluation of the proposal? > > Really useful addition > > >- Is the problem being addressed significant enough to warrant a >change to Swift? > > Yes, it is a limitation of the current language that you can't do this. > You can get round the limitation using a str

[swift-evolution] SetAlgebra naming update

Just an update: The naming guidelines working group went back into negotiation over the shape of SetAlgebra (and thus, Set and OptionSet) for Swift 3, and reached a new consensus. We intend to bring forward a proposal for the API shown here: http://dabrahams.github.io/swift-naming/SetAlgebra-

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution > wrote: > > >> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution >> mailto:swift-evolution@swift.org>> wrote >> Allow Swift types to provide custom Objective-C representations >> >> https://github.com/apple/swift-

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

Strong +1 from me, too. With the exact response as Juan. It is among the top 10 on my wish list. > On Mar 24, 2016, at 11:18 AM, Juan Ignacio Laube via swift-evolution > wrote: > > What is your evaluation of the proposal? > A strong +1 on this. > > Is the problem being addressed significant e

Re: [swift-evolution] idea: immutable setters for structs and tuples?

> On Mar 23, 2016, at 3:32 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> let john = {firstName="John"; lastName="Doe"} >> let alice = {john with FirstName="Alice"} >> >> Current way to do this in Swift is: >> >> let john = (firstName:"John", lastName:"Doe") >> var alice = john >>

Re: [swift-evolution] Notes from Swift core team 2016-03-23 design discussion

> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution > wrote > Allow Swift types to provide custom Objective-C representations > > https://github.com/apple/swift-evolution/pull/198 > > The associated type could be AnyObject rathe

Re: [swift-evolution] struct subtyping

> On Mar 21, 2016, at 7:58 AM, Tino Heth via swift-evolution > wrote: > > Many languages which adopt the concept of value types don't allow subclassing > for those, and so does Swift. > Inheritance for structs is more complex than inheritance for classes, but the > "final" limitation isn't t

Re: [swift-evolution] Catching NSException

> On Mar 24, 2016, at 11:06 AM, Jon Brooks via swift-evolution > wrote: > > Apologies if this has come up before - I've fallen behind in following this > list. > > I recently ran into an issue where I needed to be able to catch NSExceptions > raised by Objective C API in Swift, and found no

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 24, 2016, at 1:13 AM, Chris Lattner via swift-evolution > wrote: > > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate >

Re: [swift-evolution] Deprecating Trailing Closures

> I think the feature should stay but we need community guidelines on when and > when not to use them. I agree with James here. > On Mar 24, 2016, at 1:15 PM, James Campbell via swift-evolution > wrote: > > I think the feature should stay but we need community guidelines on when and > when

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

Hi Max, Thanks for sending out this proposal. I admit I’m somewhat ignorant of the current state of SwiftPM so feel free to point me at existing resources if I’m missing basic things. You don’t cover it in your proposal, but does this mean pkg-config is now a dependency for SwiftPM? I may be m

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

> On Mar 23, 2016, at 11:13 PM, Chris Lattner via swift-evolution > wrote: > How about we continue this trend, and follow other existing Swift keywords > that merge two lowercase words (associatedtype, typealias, etc), and use: > > public > moduleprivate > fileprivate >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

What is your evaluation of the proposal? A strong +1 on this. 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 Swift? Yes. If you have used other languages or libraries with a similar feature, how do

Re: [swift-evolution] Promote "primitive" types to enums in extensions

Well, I propose the “#” syntax to be consistent with other proposals that intend to provide compilation-related code. In this case, the proposal is just a way to provide an indication that a certain field within a struct or class should be enforced to be a value of a certain enum, not just a pla

Re: [swift-evolution] Deprecating Trailing Closures

> On Mar 24, 2016, at 11:57 AM, Haravikk wrote: > > >> On 24 Mar 2016, at 16:59, Erica Sadun > > wrote: >> >> I follow the "Rule of Kevin", which is not language enforced. Parens around >> functional >> closures (->T), not around procedural (->Void) ones. This pr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

The proposal is unclear to me in what it is, er, proposing. The motivation section speaks about allow `let` to be used as argument label, but the proposed solution says that func foo(let x: Int) { … } would be an error. That seems like it’s contrary to the motivations of the proposal. -Colin >

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

> On Mar 24, 2016, at 11:02, David Waite wrote: > > From "[swift-evolution] Notes from Swift core team 2016-03-23 design > discussion”: >> Make pointer nullability explicit using Optional >> >> https://github.com/apple/swift-evolution/pull/219 >>

[swift-evolution] Catching NSException

Apologies if this has come up before - I've fallen behind in following this list. I recently ran into an issue where I needed to be able to catch NSExceptions raised by Objective C API in Swift, and found no good way to do that. Currently the only possible way is to via Objective C code that wrap

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

>From "[swift-evolution] Notes from Swift core team 2016-03-23 design >discussion”: > Make pointer nullability explicit using Optional > > https://github.com/apple/swift-evolution/pull/219 > > Biggest open issue is what to do with UnsafeBuffer

[swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

Hello Swift community, The review of "Make unsafe pointer nullability explicit using Optional" begins now and runs through March 29th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md Reviews are an importan

[swift-evolution] [Review] SE-0053 Remove explicit use of let from Function Parameters

Hello Swift community, The review of "Remove explicit use of let from Function Parameters" begins now and runs through March 27th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md Reviews are an i

Re: [swift-evolution] Deprecating Trailing Closures

> On 24 Mar 2016, at 16:59, Erica Sadun wrote: > > I follow the "Rule of Kevin", which is not language enforced. Parens around > functional > closures (->T), not around procedural (->Void) ones. This promotes "language > construct"-like > Void calls, avoids compiler parsing issues when chai

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

> First of all, +1 on the idea. > > But second a question: in the Package.swift file providers section, what > would need to be done in for example the "apt" case it a package has a > different name on Debian and Ubuntu? > This is something that happens occasionally, so we should at least be abl

Re: [swift-evolution] Promote "primitive" types to enums in extensions

I would rather have a syntax that mirrors the way Protocol does it. struct Card { suit:enum value:Int } or we could change it so this only excepts the enum itself unless you explicitly cast from a Int or another enum: struct Card { suit:CardSuit value:Int } *

[swift-evolution] Promote "primitive" types to enums in extensions

It is a common practice in C to assign to integer (int, int16, int64, etc.) typed variables “constant" values declared in enums. In swift, it is in fact possible to do that by using enums' “rawValue” property. When importing structs from C into swift, we even get some fields declared with an int

Re: [swift-evolution] struct subtyping

I was treating this as a Mixin. So the property from Object is Mixed into Tree and User but it isn't a Subclass so any comparison between the two isn't possible. But on reflection you bring up a very valid point. *___* *James⎥Head Of CEO* *ja...@supmenow.com ⎥su

Re: [swift-evolution] struct subtyping

> struct Object { > let identifier: String > } > > struct User: Object { > > } > > struct Tree: Object { > } > > The last two structs get the identifier property "mixed" in but are unique > types :) Is unique meant so that User-Objects can't be used as "Object"-Object parameters? I'm asking

Re: [swift-evolution] Deprecating Trailing Closures

On 3/24/16 13:59, Erica Sadun via swift-evolution wrote: >> On Mar 24, 2016, at 10:41 AM, Haravikk via swift-evolution >> wrote: >> >>> >>> On 24 Mar 2016, at 16:13, William Dillon >> > wrote: >>> Another thing I like about trailing closures is that it allows me to

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

What is your evaluation of the proposal? +1. Especially for forcing the alias side of the declaration to explicitly keep track of type constraints. Is the problem being addressed significant enough to warrant a change to Swift? Yes. Previously, one could "work around" this by declaring a 0-case

[swift-evolution] Notes from Swift core team 2016-03-23 design discussion

To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the yesterday's discussion. (This week, I want to point out that my notes for PR 219, the first discussion topic, are es

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 24, 2016, at 12:39 AM, Russ Bishop wrote: > > >>> I added a separate section on Ambiguity and what the behavior is. I think >>> you should be able to resolve ambiguity by casting so I went ahead and put >>> that in. An example: >>> >>> //Bar and Foo bridge to SomeObjectiveCType >>>

  1   2   >