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

[John McCall via swift-evolution]

> 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 probably be very annoying to support a platform where 
>> different pointer types had different null values, but the last of those 
>> died awhile ago, I believe.
> 
> The last significant one IIRC was Itanium, in the case of C++ member pointers 
> (themselves an odd beast), which had a different representation than data 
> pointers (-1 is null).

That's not really target-specific; it's equally true for everybody using that 
C++ ABI, including us.  But member pointers are a fundamentally different 
concept from C pointers, despite the name.

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

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

[Paul Ossenbruggen via swift-evolution]

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

init?(suit: Int, rank: Int) {
guard let suit = Suit(rawValue: suit),
  let rank = Rank(rawValue: rank) else {
return nil
}
self.suit = suit
self.rank = rank
}
}

let firstCard = Card(suit: 0, rank: 3)
let secondCard = Card(suit: 3, rank: 2)
firstCard?.rank // returns Four
secondCard?.suit // returns Clubs



> On Mar 24, 2016, at 11:18 AM, Carlos Rodríguez Domínguez via swift-evolution 
>  wrote:
> 
> 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 plain 
> integer, by the compiler. Anyhow, I think many different sintaxis could be 
> elaborated. For example, another possible syntax could imply reusing the 
> typealias expression:
> 
> extension Card{
>   typealias suit:CardSuit = suit:Int
> }
> 
> However, I assume that using this syntax it should be possible to directly 
> assign to the suit field both an integer or a CardSuit.
>> b

>> On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez 
>> > wrote:
>> 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 integer 
>> type, but expecting the assignment of a “constant” declared inside an enum. 
>> Of course, this is error prone, it is “old-style” programming and very 
>> confusing for newcomers. To solve this issue, my proposal is to be able to 
>> create extensions that promote certain fields within a class or struct to 
>> enums.
>> 
>> For instance, let’s take these sample C struct and enum:
>> 
>> struct Card {
>> int suit;
>> int rank;
>> };
>> 
>> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>> 
>> (Note: I understand that above code follows a bad programming practice, yet 
>> it is widely common)
>> 
>> It should be imported into swift as follows:
>> 
>> struct Card {
>> suit:Int
>> value:Int
>> }
>> 
>> enum CardSuit : Int {
>> case Hearts, Diamonds, Clubs, Spades
>> }
>> 
>> Now, I propose to be able to create an extension as follows:
>> 
>> extension Card {
>> #enumvalue(suit:CardSuit)
>> }
>> 
>> From this moment on, the suit field should only receive CardSuit values, 
>> thus not requiring the use of raw values for assignments.
>> 
>> These extensions should also be of great interest for people using CoreData, 
>> since it is not possible to declare enums in models. Therefore, to declare 
>> enums, it is necessary to declare integer values, and then use the “unsafe”, 
>> “unexpressive" approach explained before.
>> 
>> Note that the proposal intends to only support promotions from integer 
>> values to enum values, but, for example, it could also be extended to string 
>> values.
>> 
>> Finally, it could be appropriate to extend this proposal to redeclare func’s 
>> signatures, in order to promote certain parameters to enum values.
>> 
>> Best,
>> 
>> Carlos.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Colin Barrett via swift-evolution]

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 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.
> 
> The proposal is simply that "func foo(let x: Int) { … }” be disallowed, since 
> it is redundant with "func foo(x: Int) { … }”.  In terms of taking back “let” 
> as a parameter label, this only makes sense in the future, when we give up on 
> migration of the former into the later.
> 
> At that point, let could conceivably be used as an external label, as in 
> "foo(let: 42)”.  This would make the language simpler and more consistent, 
> since we allow other keywords there.
> 
> -Chris
> 
>> 
>> -Colin
>> 
>>> On Mar 24, 2016, at 2:00 PM, Chris Lattner  wrote:
>>> 
>>> 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 important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at:
>>>https://lists.swift.org/mailman/listinfo/swift-evolution
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and, eventually, determine the direction of 
>>> Swift. When writing your review, here are some questions you might want to 
>>> answer in your review:
>>> 
>>>* What is your evaluation of the proposal?
>>>* Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>>* Does this proposal fit well with the feel and direction of Swift?
>>>* If you have you used other languages or libraries with a similar 
>>> feature, how do you feel that this proposal compares to those?
>>>* How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>>https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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 different 
> pointer types had different null values, but the last of those died awhile 
> ago, I believe.

The last significant one IIRC was Itanium, in the case of C++ member pointers 
(themselves an odd beast), which had a different representation than data 
pointers (-1 is null).

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

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

[Chris Lattner via swift-evolution]

> 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 an error. 
> That seems like it’s contrary to the motivations of the proposal.

The proposal is simply that "func foo(let x: Int) { … }” be disallowed, since 
it is redundant with "func foo(x: Int) { … }”.  In terms of taking back “let” 
as a parameter label, this only makes sense in the future, when we give up on 
migration of the former into the later.

At that point, let could conceivably be used as an external label, as in 
"foo(let: 42)”.  This would make the language simpler and more consistent, 
since we allow other keywords there.

-Chris

> 
> -Colin
> 
>> On Mar 24, 2016, at 2:00 PM, Chris Lattner  wrote:
>> 
>> 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 important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>>  https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager.
>> 
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  * What is your evaluation of the proposal?
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  * Does this proposal fit well with the feel and direction of Swift?
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>>  https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> -Chris Lattner
>> Review Manager
>> 
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Russ Bishop via swift-evolution]

> On Mar 24, 2016, at 1:26 PM, Chris Lattner  wrote:
> 
> 
>> 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 
>>> > wrote
>>> Allow Swift types to provide custom Objective-C representations 
>>> 
>>> https://github.com/apple/swift-evolution/pull/198 
>>> 
>>> The associated type could be AnyObject rather than NSObject. The use case 
>>> for a non-subclass of NSObject is very narrow, but it’s not a needed 
>>> restriction.
>>> 
>>> The unconditionalyBridgeFromObjectiveC function can probably go away. 
>>> Calling initializers from the downcasting infrastructure is horrible. If we 
>>> need a function, they
>>> 
>> Was there more to this line of thought? It looks like it got cut off.
>> 
>> I would like to unify this to either have the initializers or have the 
>> static functions but not both, but I don’t know which is preferred from an 
>> implementation perspective. The initializers feel more “Swifty” but moving 
>> back to static functions is perfectly workable.
> 
> The preference was to just have the initializers, since that is the preferred 
> way to express conversions.


Sounds good to me; I updated the proposal to use initializers.



Russ

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

Re: [swift-evolution] SetAlgebra naming update

[Xiaodi Wu via swift-evolution]

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
>> from" (also, inconsistent, because you don't have "form union with")
>
> Good point.  What would you suggest?  We could use “with:” everywhere in
> the “formXXX” methods...

For the nonmutating method, maybe just `x = y.symmetricDifference(z)`.
Prepositions are useful to have because they clarify the relationship
between two or more things--but here, by construction, it's symmetric.
For the mutating methods, either `y.formXXX(with: z)` or
`y.formXXX(z)` look good to me.

>
>> * "form" is fine, but scans similarly to "from" when reading quickly
>
> That's a good point.  Maybe that's another good reason to drop “from:”
> as a preposition in formSymmetricDifference.

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

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

[Joe Groff via swift-evolution]

> 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 not a postfix unary operator
>  }
> }
> 
> Which is why I found it necessary to add a typealias like so…
> 
> extension PropertyType
> {
>  private static func create() -> Property
>  {
>typealias SelfType = Self
> 
>return Property.init()
>  }
> }

Oops, that's definitely a bug.

> This doesn't compile either…
> 
> struct PropertyFactory
> {
>  static func createBoundPropertywithValueType(valueType: PropertyType.Type) 
> -> PropertyProtocol
>  {
>return valueType.create()
>^ Member 'create' cannot be used on value of protocol type 
> 'PropertyType'; use a generic constraint instead
>  }
> }
> 
> For some reason, as soon as you change the PropertyType extension static func 
> to return PropertyProtocol…
> 
> extension PropertyType
> {
>  private static func create() -> PropertyProtocol
>  {
>typealias SelfType = Self
> 
>return Property.init()
>  }
> }
> 
> … then, and only then, the factory's method compiles correctly.

Oops, my fault, this one is by design. Since we're calling through a dynamic 
type, our type system isn't able to express the result type 
`Property`, so we need to abstract it behind the PropertyProtocol.

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

That one's easy, at least—you can take `Any.Type` and use `as?` to cast it to 
`PropertyType.Type`.

> What would really make life easier here would be the ability to extend Any.
> 
> Any chance?

I think that'd be cool. Some people fear the power (and ensuing responsibility) 
that unleashes, though…

-Joe

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

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

[Matthew Johnson via swift-evolution]

>   * 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 direction of Swift?

Very much so.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

It aligns well with languages that improve safety by explicitly modeling null. 

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed the discussion and read the proposal.  I was very pleased to see 
Jordan propose this.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] NSCoding-like Persistence

[Jonathan Hull via swift-evolution]

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 powerful/flexible using 
protocols and value types.  The one problem I keep running into, however, is 
how to persist things in the same way you can with NSCoding.  NSCoding requires 
NSObject as a base class.

I spent the last couple of weekends playing with ideas for a persistence 
framework and I was able to get about 90% of the way there.  I was able to 
encode types like [(Int,Float)] by supplying closures to the encoding function. 
 For example:  func encodeArray(array:[T], forKey:String, 
mapping:(T)->Encoding).  There is a simpler version without the closure for 
arrays where T adheres to my “Encodable” protocol:  func 
encodeArray(array:[T], forKey:String).  I also have legacy support 
for objects which adhere to NSCoding.

Instead of going straight to data like NSCoding, I encode to an intermediate 
format (A struct with an internal enum).  Then you have another protocol which 
can turn that format into data, json, plist, etc…

90% working, but I ran into a few problems.  First, I have to use this horrible 
thing to get the type system to cooperate in some cases:

func horribleAutocastHack(x:Any, fail:(()throws-> T)? = nil)throws -> T{
if let cast = x as? T{
return cast
}
if let fail = fail{
return try fail()
}
fatalError("Autocast failed")
}


Second, I had to use static methods instead of init in my protocol, since init 
fails on classes where I don’t have access to the code (e.g. NSData).  It wants 
me to mark it both required and final, which I can’t do.

Third, I have no idea how to persist closures. It may just be flat out 
impossible.  The big effect it has had is that anywhere where I had to build a 
thunk to store a collection of heterogeneous objects (adhering to a protocol 
with self requirements) it can no longer be persisted.  This is actually the 
biggest issue, and I haven’t even been able to hack around it.

Finally, I am pushing the generics system pretty hard.  My first version was 
randomly crashing the compiler so I had to pull back on that front (e.g. having 
encodeArray instead of just encode which infers the arrayness).  All of the 
various discussions around factory methods are also relevant.

I was able to get the rest working though.  

Is there an official plan which I am duplicating effort on?  I would be happy 
to share my code (after a couple more iterations) if that would be 
helpful/inspiring.  I would also be happy to just work on other things and wait 
for the official solution if there is one coming…  I may have to wait for more 
powerful generics in any case.

I feel like this is one of those things that is impacting a lot of real world 
codebases, and delaying adoption of POP, value types, etc...

Thanks,
Jon

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

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

[Matthew Johnson via swift-evolution]

> 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 well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Yes, it is very similar.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
This is a feature I have wanted since the beginning.  I followed the discussion 
and read the proposal.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Dave Abrahams via swift-evolution]

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
>>> displayed, a listener that needs to be stored somewhere, etc).
>> 
>> To be clear, the mistake this warning prevents is the unintentional call
>> to a non-mutating method when one thinks one is mutating the receiver.
>> This scenario can arise independently of A or B.
>
> Sure. Although if a type only has mutating or non-mutating methods,
> but not both, the mistake will probably be immediately apparent, 

Why do you think so?

> so the diagnostic doesn't win you much (except maybe in a newbie
> learning environment, which is an important use case as well).
>
> A.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

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

[Brent Royal-Gordon via swift-evolution]

> 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-friendly Strideable.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SetAlgebra naming update

[Erica Sadun via swift-evolution]

> 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 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-Math.html
>>> 
>>> and to update the guidelines to suggest using the "form" prefix to
>>> create a verb phrase for a mutating method when the operation is
>>> fundamentally non-mutating and described by a noun.
>> 
>> I've got to say, I expected to hate this until I clicked the link and saw 
>> the actual 
>> proposed syntax. For the most part, it's good: clear and readable.
>> 
>> Not a fan of "subtracting" (would prefer "bySubtracting"). Other than that
>> really impressed by how this evolved.
> 
>  x by subtracting y
> 
> means, “give me x, and get it by subtracting y.”  The use of “byXXXing”
> in existing Cocoa APIs doesn't really set a precedent because it was
> always preceded by a noun that described the result being returned,
> e.g. “x.stringByAppending(y),” which is a completely different thing.
> 

So far in each of the naming situations where I have disliked a particular form
("subtracting" here), the final results have been good.  Apparently
the strategy of pointing out the bad points and letting magic happen behind
the scenes is a successful one.

Because that's not very helpful: 

* excluding
* differenceFrom
* minus
* excepting
* subtractingElementsFrom / subtractingElements(from: or of:
 
-- E

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

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

[Dave Abrahams via swift-evolution]

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 short and to 
> be more flexible.
> Removing constraints on Index, useful for linked lists etc.
> Changing the way Range works to that it plays nicer with a larger range of 
> types; range[index] = start + index * stride
> Flattening the hierarchy, to allow a mix and match approach to features for 
> more flexibility.
>
> Saying problem to be solved is too strong. There is no real problem
> with the current collections. They work just fine. However I think
> they could be finessed. Much like many of the things discussed on
> swift-eveolution :(
>
>> On 25 Mar 2016, at 8:28 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> 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 post.
>>> 
>>> They differ from the current collections API and the new proposed 
>>> collections API in that:
>>> 
>>> 1. They use the existing external iterator, 
>> 
>> You mean index.
>
> For the proposed new collections you would write:
>
> var iterator = array.iterator
> let element = array.next()

In your proposal?  That's not what we're intending to bring forward.


-- 
Dave

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

Re: [swift-evolution] SetAlgebra naming update

[Dave Abrahams via swift-evolution]

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, and reached a new consensus.  We intend to bring forward a
>> proposal for the API shown here:
>> 
>>  http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>> 
>> and to update the guidelines to suggest using the "form" prefix to
>> create a verb phrase for a mutating method when the operation is
>> fundamentally non-mutating and described by a noun.
>
> I've got to say, I expected to hate this until I clicked the link and saw the 
> actual 
> proposed syntax. For the most part, it's good: clear and readable.
>
> Not a fan of "subtracting" (would prefer "bySubtracting"). Other than that
> really impressed by how this evolved.

  x by subtracting y

means, “give me x, and get it by subtracting y.”  The use of “byXXXing”
in existing Cocoa APIs doesn't really set a precedent because it was
always preceded by a noun that described the result being returned,
e.g. “x.stringByAppending(y),” which is a completely different thing.


-- 
Dave

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

Re: [swift-evolution] SetAlgebra naming update

[Dave Abrahams via swift-evolution]

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 would you suggest?  We could use “with:” everywhere in
the “formXXX” methods...

> * "form" is fine, but scans similarly to "from" when reading quickly

That's a good point.  Maybe that's another good reason to drop “from:”
as a preposition in formSymmetricDifference.

>
>
> On Thu, Mar 24, 2016 at 3:41 PM Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> 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 forward a
>> proposal for the API shown here:
>>
>>   http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>>
>> and to update the guidelines to suggest using the "form" prefix to
>> create a verb phrase for a mutating method when the operation is
>> fundamentally non-mutating and described by a noun.
>>
>> Regards,
>>
>> --
>> Dave
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
Dave

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

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

[Dave Abrahams via swift-evolution]

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 startIndex and endIndex
independently.


-- 
Dave

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

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

[Jonathan Hull via swift-evolution]

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 possible, while 
> still providing enough flexibility and use cases to warrant it.

I can definitely see the argument that extensibility is out of scope for Swift 
3, but I do want to make sure that it is possible for us to have extensibility 
in the future (that we don’t block ourselves from doing it).

I strongly disagree that the gain is small.  One of the core benefits of both 
Swift/ObjC (and now POP) is the ability to extend things post-hoc, without 
access to the original code.

I often write libraries & SDKs, so the users of my code don't have access to 
the original code.  I guess extensibility is less necessary when you control 
the entire codebase, but you still have to refactor your factory whenever you 
subclass (or adhere to a protocol), which I find problematic.

This is something I run into a lot while writing actual code, so it isn’t just 
a theoretical concern.



> Interesting you bring up the registering of subclasses, as that is similar to 
> the very original proposal, and actually similar to what I'm doing in my own 
> app. Effectively, I have an Objective-C base class, and in +load it 
> dynamically finds all subclasses using the Objective-C runtime, and stores a 
> reference to them. Then in the initializer, it returns the appropriate 
> subclass based on the initialization parameters. This was my solution to the 
> superclass not having to explicitly know each individual subclass.
> 
> Using factory initializers, however, this pattern could be used in pure 
> Swift, albeit with some minor modifications. At program start, the program 
> could register subclasses with the superclass, and then in the initializer 
> would simply return the appropriate subclass (similar to NSURLProtocol, I 
> believe).

Yes, I have also used load in this way in ObjC.  In Swift, I think the compiler 
could easily build an array/table of the overloads of factory inits.  This 
avoids having to register explicitly (the declaration itself implies intent to 
register), and doesn’t take up any cycles during execution.

I ran into the problem of when to register the other day in a current project, 
as Swift doesn’t have an equivalent to +load that I am aware of.  I had to 
settle for something of a hack which gets called on first use… but it was only 
a partial solution which worked in that particular case.  How do the swift 
classes/enums/structs get called to register themselves?

We may want to propose adding a +load equivalent for Swift types, since it does 
come up occasionally. It is one of those things which you don’t need often, but 
when you do, you really need it.  Ironically, this was one of the uses of the 
original feature I talked about earlier (we used it to provide the equivalent 
of +load, awakeFromNib, etc… in the language). 



> As for rationale for protocol (factory) initializers, a common pattern I've 
> come across when developing my internal frameworks is to design a protocol, 
> and then to provide a default implementation of the protocol with a type 
> (typically a struct). I feel this relationship could be bridged easier by 
> simply returning this type from a protocol initializer, which could even 
> potentially allow me to declare the actual type as private, so for all 
> intents and purposes the client does simply get an initialized protocol 
> object (similar in part to creating an anonymous class conforming to a 
> protocol in Java).

I strongly agree that we should have factory initializers for protocols for the 
reasons you state here, plus many others.  It just seems like a natural fit.


I would like to see a 3 stage approach:

Stage 1:  Declaring an init as “factory” allows you to return any fully inited 
object which fits the type (including calling self.init like a convenience init 
would and then returning it). If the init is failable, you can also return nil. 
 This works both on classes and protocols.

Stage 2:  The compiler builds a table of the overrides of a given factory init, 
and there is some syntax to call them (e.g. “let sub = subclasses.init(value)”) 
such that the first one to return non-nil is the return value to that call.  
Thorsten’s depth first + alphabetical ordering would be adequate to make the 
behavior predictable.  Again, this should work for both classes and protocols. 
(I am open to better ideas for syntax/naming)

Stage 3: We allow greater control over the ordering in the table. This still 
needs thought both on syntax and method.  Something similar to operator 
precedence (or autolayout priority) would work in a pinch, but isn’t super 
elegant. In practice, it might be enough just to be able to declare that 
something needs to be 

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

[Howard Lovatt via swift-evolution]

+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 “♠️" }
   }
   case Diamonds {
   var description: String { return “♦️" }
   }
   case Clubs {
   var description: String { return “♣️" }
   }

   // ...
}

The compiler could automatically generate the switch statement if that was 
better than virtual dispatch.


> On 25 Mar 2016, at 2:42 AM, David Waite via swift-evolution 
>  wrote:
> 
> In Java, the enum type behaves as an abstract class, sealed against the case 
> members (which are singleton instance subclasses.)
> 
> While Swift enums aren’t discrete types or singletons, it sounds like what 
> you would like is the ability to have an enum behave as so - to be able to 
> override base (or protocol extension) behavior with a particular enum case, 
> and have that translated most likely into a switch statement (most likely - I 
> suppose if you are using witness tables it could optimize the switch away)
> 
> Actually with a protocol default behavior being overridden with a single enum 
> case, this would give you functionality not possible today (referencing that 
> protocol extension method)
> 
> In Java, I exploit the enum behavior to implement the State design pattern 
> quite a bit, but am limited as Java enums are singletons and thus should be 
> isolated from state. Swift enums are even more powerful here, but doing this 
> in switch statements is a pain for maintainability.
> 
> I like the idea
> 
> -DW
> 
> 
>> On Mar 23, 2016, at 4:13 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> If you've written enums before, you've no doubt noticed the irritating 
>> phenomenon of `switch self` being absolutely everywhere. I first discovered 
>> this in some of my very first Swift code, code so old we were still using 
>> the `T[]` shorthand syntax:
>> 
>>   enum Suit: Int {
>>   case Hearts, Spades, Diamonds, Clubs
>> 
>>   static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
>> 
>>   var description: String {
>>   switch(self) {
>>   case .Hearts:
>>   return "♥️"
>>   case .Spades:
>>   return "♠️"
>>   case .Diamonds:
>>   return "♦️"
>>   case .Clubs:
>>   return "♣️"
>>   }
>>   }
>> 
>>   var isRed: Bool {
>>   switch(self) {
>>   case .Hearts, .Diamonds:
>>   return true
>>   case .Spades, .Clubs:
>>   return false
>>   }
>>   }
>>   }
>> 
>> It would be nice if we could somehow eliminate that. I have two suggestions:
>> 
>> * Implicitly switch on `self` at the top level of a function or accessor (or 
>> at least an enum one with top-level `case` statements).
>> 
>>   enum Suit: Int {
>>   case Hearts, Spades, Diamonds, Clubs
>> 
>>   static var all = [ Hearts, Spades, Diamonds, Clubs ]
>> 
>>   var description: String {
>>   case .Hearts:
>>   return "♥️"
>>   case .Spades:
>>   return "♠️"
>>   case .Diamonds:
>>   return "♦️"
>>   case .Clubs:
>>   return "♣️"
>>   }
>> 
>>   var isRed: Bool {
>>   case .Hearts, .Diamonds:
>>   return true
>>   case .Spades, .Clubs:
>>   return false
>>   }
>>   }
>> 
>> * Allow you to attach member definitions to particular cases. It would be an 
>> error if they didn't all define the same members, unless there was a 
>> top-level catchall.
>> 
>>   enum Suit: Int {
>>   var isRed: Bool { return false }
>> 
>>   case Hearts {
>>   let description: String { return "♥️" }
>>   let isRed: Bool { return true }
>>   }
>>   case Spades {
>>   let description: String { return  "♠️" }
>>   }
>>   case Diamonds {
>>   let description: String { return  "♦️" }
>>   let isRed: Bool { return true }
>>   }
>>   case Clubs {
>>   let description: String { return  "♣️" }
>>   }
>> 
>>   static var all = [ Hearts, Spades, Diamonds, Clubs ]
>>   }
>> 
>> Any thoughts? This has, to be honest, bothered me since approximately the 
>> third day I used the language; I'd love to address it sooner or later.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list

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

[Joanna Carter via swift-evolution]

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

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

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

[Brent Royal-Gordon via swift-evolution]

>   * 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 pointer types less expressive than C, which is just *wrong*. Making 
nullability explicit is a good move.

>   * 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 you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

The nullability specifiers introduced recently in clang have markedly removed 
my Objective-C code, both by better documenting system APIs and by forcing me 
to improve my own calls.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal, participated in discussion.

-- 
Brent Royal-Gordon
Architechies

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

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

[Daniel Vollmer via swift-evolution]

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

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

[Brent Royal-Gordon via swift-evolution]

> 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 able to do this.

I don't think this is mentioned in the proposal itself, but it came up in the 
discussion.

The C standard requires that there be a "null" pointer address which can be 
stored into any pointer but which can never actually be valid. It does *not* 
require that the null pointer address be 0x0. Most platforms do use 0x0, and 
clang doesn't support a non-0x0 null pointer, but this is not required by the C 
standard.

I believe Swift should mimic this behavior. On platforms where 0x0 is a valid 
address, Swift should not use 0x0 as the null pointer, but rather use some 
other address which isn't valid (perhaps ~0x0). Pointer types should treat this 
address as an unused value, which the enum machinery will then exploit to 
represent Optional.none.

For now, this design should probably just be documented somewhere, perhaps in a 
porting guide; actually implementing it is not really a priority.

> Finally, having nullable UnsafePointers currently is the only way from swift 
> code to convert an UnsafePointer to an Int of its raw address, short of using 
> another level of indirection:
> 
> let rawAddress: Int = UnsafePointer(nil).distanceTo(myPointer)

Given what I discussed about `nil` not necessarily being 0x0, this construct is 
not necessarily valid anyway.

Besides, we *do* have a construct which converts between pointers and integers 
without any semantic confusion about `nil`—and it even expresses what it's 
doing more clearly than your `distanceTo` trick:

unsafeBitCast(pointer, Int.self)

> I'm actually unsure of any other languages that have explicit nullability on 
> a raw pointer type. (Maybe rust has it? I'm not very familiar with rust).

Apple variants of C, C++, and Objective-C now do. Actually, I believe they had 
some nullability control even before the recent keywords through __attribute__.

-- 
Brent Royal-Gordon
Architechies

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

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

[Brandon Knope via swift-evolution]

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 up and 
> know that it's an access modifier?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I'm with you here too. I'm not opposed to it but it strikes me as being 
hypertechnical and unnecessarily verbose. 

It's also not symmetrical: where is modulepublic and filepublic? Those don't 
make sense? Then module and file stand on their own if private is implied (you 
know people will wonder when they see moduleprivate if a public one exists)

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

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

[Brent Royal-Gordon via swift-evolution]

>   * 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 don't think it's a good idea to set a precedent that even facepalmingly 
obvious mistakes in proposals can only be fixed with a full review cycle.

Rather, I think this proposal should be rejected and, after a simple, informal 
discussion on the list, SE-0003 should be amended to eliminate the `let` 
keyword. There is precedent for rejecting a proposal because the proposal 
shouldn't have been necessary: SE-0013 "Remove Partial Application of Non-Final 
Super Methods" 

 was rejected because the core team decided the evolution process wasn't right 
for that particular change.

I believe the core team should do that again here, rather than turning the 
evolution process into a straightjacket preventing it from making simple, 
straightforward, and obviously correct changes which have already passed review 
in spirit, if not in letter.

-- 
Brent Royal-Gordon
Architechies

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

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

[Colin Barrett via swift-evolution]

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 mean pkg-config is now a 
>> dependency for SwiftPM? I may be mistaken but it doesn’t seem as though 
>> pkg-config is installed on the base OS X system. (This leads me to assume 
>> it’s an optional dependency.)
> 
> This is a good point, I’ll revise the proposal.
> 
> My intentions were: if available, use it, if not, then things may not build. 
> Long term we could parse pkg-config files ourselves since the format is very 
> basic which would be preferable since “your package graph *may* or *may not* 
> build” is hardly fun

Great! Myself, I would just parse the pc files straight away. Avoiding 
dependencies seems  highly desirable for something this low in the stack.

>> Your proposal suggests the set of supported package mangers will be closed. 
>> What about folks using new, or non-standard package managers?
> 
> They can add their package manager to the supported list via a Pull Request.

This is a surprising answer! Just to be clear―what functionality, specifically, 
is this enabling?

>> What about packages that are installed system-wide without a package manager 
>> (e.g. with ./configure && make && make install)? 
> 
> Such packages should come with a .pc file.
> 
>> This may be covered elsewhere, but about the case of a C package that is 
>> normally system-wide but is currently being hacked on by the user? (For 
>> example to while debugging it, or writing bindings for it.)
> 
> There is no convenient way to do this at this time, but proposals are 
> welcome. It *is* possible currently, you can make a local module map package 
> that encapsulates the C library, or if it is simple enough our C-target 
> support may be sufficient

No proposal here, but this is more common than you'd think―it merits at least 
an FAQ in the final proposal.

Thanks Max!
-Colin

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

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

[Erica Sadun via swift-evolution]

> 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 it up and 
> know that it's an access modifier?

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 
less flexible in meaning and 
more fixed in purpose.

I hesitate to make this thread any longer but since it's already bikeshedding, 
I felt it was worth adding another few cents.

-- E

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

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

[Brent Royal-Gordon via swift-evolution]

> 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 benefits of clear word boundaries far outweigh the keystroke cost 
> (especially with good editor auto-complete).

Swift style, deriving from Objective-C style, seems to disfavor underscores in 
general, except as a "formally public but informally private" marker at the 
beginning of an identifier. We're in the process of removing the last 
underscored language constructs, `@warn_unused_result` and its 
`mutable_variant` parameter, and replacing them with alternatives without 
underscores.

So if we wanted to mark a word boundary, we'd probably use camelCase. And to 
me, camelCase just feels wrong for keywords, particularly ones as common as 
access modifiers. I think it's because identifiers are camelCase too; you 
really want keywords to disappear into the background, but in something like 
this:

modulePrivate func spinWicket() {

That `modulePrivate` looks like an identifier—maybe a return type or 
something—rather than a keyword.

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 up and know that 
it's an access modifier?

-- 
Brent Royal-Gordon
Architechies

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

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

[Howard Lovatt via swift-evolution]

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 Index, useful for linked lists etc.
Changing the way Range works to that it plays nicer with a larger range of 
types; range[index] = start + index * stride
Flattening the hierarchy, to allow a mix and match approach to features for 
more flexibility.

Saying problem to be solved is too strong. There is no real problem with the 
current collections. They work just fine. However I think they could be 
finessed. Much like many of the things discussed on swift-eveolution :(

> On 25 Mar 2016, at 8:28 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 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 post.
>> 
>> They differ from the current collections API and the new proposed 
>> collections API in that:
>> 
>> 1. They use the existing external iterator, 
> 
> You mean index.

For the proposed new collections you would write:

var iterator = array.iterator
let element = array.next()

You can’t type erase the returned iterator because it must be called on the 
original array and therefore must be of the type that that specific array’s 
next method accepts, not an arbitrary AnyIterator type. These proposed 
iterators are a cross between an internal and external iterator.

The current and the iterator I used are classic internal iterators and 
therefore can be type erased because they encapsulate the collection being 
iterated and the iteration state.

> 
>>`iterator.next()`, rather
>>than the proposed style, `iterator.next()`, because the new style
>>ties the iterator to a particular collection type and therefore
>>cannot be type erased.
> 
> The new style does not prevent type erasure.  See
> https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/ExistentialCollection.swift.gyb
> for an example.

This is for the current behaviour which I used. Is this the correct reference?

> 
>>Type erasure is required to keep return types generic, e.g. rather than
>>map returning an Array it returns an `AnyNextorable` (see point 
>> 5 below).
>> 2. The protocols are not, in general, heirarchical; instead they are small 
>> building blocks at the top level that can be fitted together.
>> 3. Protocols are split when a good default implementation cannot be 
>> provided, e.g. CountableCollection is seperate because the default of 
>> iterating and
>>counting the elements is not a good implimentation of count.
>> 4. Hierarchies are used for convenience, e.g. ArrayCollection is a 
>> convenience protocol that extends base protocols.
>> 5. The protocol member's return generic implementations of protocols, e.g. 
>> where you might return an Array instead you return an 
>> `AnyNextorable`.
>>This sidesteps issues with associated types and generics and prevents 
>> large type signatures. The downside is that you have comitted to a particular
>>interface and therefore lost covariance. When generics are completed 
>> hopefully these return types can be replaced with `Any<... where ...>`, e.g. 
>> `Any
>>`
>> 6. LazyNextable is split out seperately so that the semantics of lazy are 
>> articulated in the type system. The design of LazyNextable is also compatible
>>with adding ParallelLazyNextable in the future.
>> 7. The naming of the protocols is one of:
>> 1. Xxxable because it is a main behavioural protocol and its main member 
>> is xxx, e.g. Nextorable has a main property nextor.
>> 2. If in the rare case that a protocol extends another protocol then the 
>> new property is prepended, e.g. MutableSubstriptable extends Substriptable
>>and the main method added is mutable subscripting.
>> 3. If they don't have a main member then they are named after what they 
>> are used for, e.g. ArrayCollection defines the members of Array like
>>collections. Note name format of XxxCollection.
>> 4. AnyXxxx is a type erased implimentation of Xxx, e.g. AnyLazyNextable 
>> is an erased LazyNextable.
>> 5. Xxxee and xxxee is used for the subject of an action, e.g. Rangee is 
>> a collection of methods that a type must impliment to be used in a Range.
>> 8. Range has an Int index of 0 to count - 1 and a value of start + index * 
>> stride, where start and stride are of type Rangee. Int and Double via 
>> extension
>>are made Rangees.
>> 9. Index, used in Subscriptables, can be any type.
> 
> Let's cut to the chase: what problem are 

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

[Andrey Tarantsov via swift-evolution]

> 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 benefits of clear word boundaries far outweigh the keystroke cost 
> (especially with good editor auto-complete).

The keywords, unlike identifiers, are always the same. You don't need to parse 
them every time; ‘on an infinite timescale’, you get used to them and recognize 
them at a glance. So the value of adding an underscore (or, heaven forbid, 
camel case style) to a keyword is a lot less than with identifiers.

My personal completely subjective opinion is that the underscored ones look 
gross and pull too much attention onto themselves, rather than helping to focus 
on the identifiers. To me, this actually detracts from the overall readability 
of the entire line.

In other words: nothing says “nothing to see here, move along” quite like 
abunchofgibberishthrowntogether.

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

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

[Max Howell via swift-evolution]

> 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 mistaken but it doesn’t seem as though 
> pkg-config is installed on the base OS X system. (This leads me to assume 
> it’s an optional dependency.)

This is a good point, I’ll revise the proposal.

My intentions were: if available, use it, if not, then things may not build. 
Long term we could parse pkg-config files ourselves since the format is very 
basic which would be preferable since “your package graph *may* or *may not* 
build” is hardly fun.

> Your proposal suggests the set of supported package mangers will be closed. 
> What about folks using new, or non-standard package managers?

They can add their package manager to the supported list via a Pull Request.

> What about packages that are installed system-wide without a package manager 
> (e.g. with ./configure && make && make install)? 

Such packages should come with a .pc file.

> This may be covered elsewhere, but about the case of a C package that is 
> normally system-wide but is currently being hacked on by the user? (For 
> example to while debugging it, or writing bindings for it.)

There is no convenient way to do this at this time, but proposals are welcome. 
It *is* possible currently, you can make a local module map package that 
encapsulates the C library, or if it is simple enough our C-target support may 
be sufficient.

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

Re: [swift-evolution] SetAlgebra naming update

[Ricardo Parada via swift-evolution]

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:
subtracting / subtract 

to: 
difference / formDifference

in order to keep the API consistent. 

Thanks

> On Mar 24, 2016, at 5:35 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 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, 2016 at 3:41 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 forward a
>> proposal for the API shown here:
>> 
>>   http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>> 
>> and to update the guidelines to suggest using the "form" prefix to
>> create a verb phrase for a mutating method when the operation is
>> fundamentally non-mutating and described by a noun.
>> 
>> Regards,
>> 
>> --
>> Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Randrup via swift-evolution]

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 ,
> 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 currently in the
> middle of a move and multiple travel plans, so I can't spearhead this for
> another week or two.
>
> Jacob
>
> On Thu, Mar 24, 2016 at 2:23 PM, Kevin Randrup via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> # 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
>> RawRepresentable initializer (SO link
>> 
>> ).
>>
>> I'm presenting this idea here for discussion and feedback before I write
>> up a formal proposal.
>>
>> # Limits
>> Having an allValues method would only be logical for enums which do not
>> have associated values. This limits the enum to RawRepresentable enums and
>> basic enums (is there a name for an enum without associated values and no
>> raw value?).
>> I'm working with the assumption that this would only be done with
>> RawRepresentable enums but it may be the case that basic enums can be
>> included easily.
>>
>> # Examples
>> All examples as source code are available as a gist
>> .
>>
>> enum CommandLineFlag : String {
>> case Version = "--version"
>> case Help = "--help"
>> case Start = "--start"
>> }
>>
>> func displayHelp() {
>> print("Available flags\n")
>> for flag in CommandLineFlag.allValues {
>> print("\(flag): \(flag.rawValue)")
>> }
>> }
>>
>>
>>
>> Representing the structure and implementing UITableViewDataSource methods
>> enum RecipeTableViewSection : Int {
>> case Header
>> case Details
>> }
>>
>> enum RecipeHeaderRow : Int {
>> case Name
>> case Image
>> }
>>
>> enum RecipeDetailRow : Int {
>> case Ingredients
>> case Cost
>> case PreparationTime
>> }
>>
>> // UITableViewDataSource implementation
>> func tableView(tableView: UITableView, numberOfRowsInSection section:
>> Int) -> Int {
>> switch RecipeTableViewSection(rawValue: section)! {
>> case .Header:
>> return RecipeHeaderRow.allValues().count
>> case .Details:
>> return RecipeDetailRow.allValues().count
>> }
>> }
>>
>> func numberOfSectionsInTableView(tableView: UITableView) -> Int {
>> return RecipeTableViewSection.allValues().count
>> }
>>
>> # Decisions/Questions
>>
>> 1. Function vs. computed property vs. stored static variable
>>
>> static func allValues() -> [CommandLineFlag] {
>>   return [Version, Help, Start]
>> }
>>
>>
>> static var allValues: [CommandLineFlag] {
>>   return [Version, Help, Start]
>> }
>>
>> static let allValues = [Version, Help, Start]
>>
>>
>>- Currently leaning towards computed property
>>   - Computed property > function - allValues doesn't do anything
>>   besides return a value so it doesn't need to be a function
>>   - Computed property > stored static variable - Will not increase
>>   the memory usage of the program
>>   - A change between computed and stored static property would not
>>be a source breaking change if it turns out one is better than the other.
>>
>> 2. Set vs. Array
>>
>>- Set - There are no duplicate values and RawRepresentable enums
>>already conform to Hashable/Equatable.
>>- Array - Preserves the cases' declaration order
>>
>> 3. Should allValues consist of the enum type or RawValue?
>> (CommandLineFlag vs. String)
>>
>>- Strongly learning towards enum type
>>- However, either one could be converted to the other and one could
>>simply be a computed property of the other.
>>
>>
>> If you have better examples and use cases, I would love to hear about
>> them before writing the proposal.
>>
>>  - Kevin Randrup
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 now:
>> 
>> struct Person {
>>var firstName, lastName: String
>> }
>> 
>> func modify(item: T, update: (inout T) -> Void) -> T {
>>var this = item
>>update()
>>return this
>> }
>> 
>> let carol: Person = modify(john) {
>>$0.firstName = "Carol"
>> }
>> 
>> print(carol)
> 
> You *can* do this now. I'm suggesting it be added to Stdlib.
> 

Ah, then that's a "pass it by Dmitri" kind of thing, isn't it?

-- E


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

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

[Brent Royal-Gordon via swift-evolution]

>> 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
> }
> 
> func modify(item: T, update: (inout T) -> Void) -> T {
> var this = item
> update()
> return this
> }
> 
> let carol: Person = modify(john) {
> $0.firstName = "Carol"
> }
> 
> print(carol)

You *can* do this now. I'm suggesting it be added to Stdlib.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] SetAlgebra naming update

[Xiaodi Wu via swift-evolution]

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, 2016 at 3:41 PM Dave Abrahams via swift-evolution <
swift-evolution@swift.org> 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 forward a
> proposal for the API shown here:
>
>   http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>
> and to update the guidelines to suggest using the "form" prefix to
> create a verb phrase for a mutating method when the operation is
> fundamentally non-mutating and described by a noun.
>
> Regards,
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

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 post.
>
> They differ from the current collections API and the new proposed collections 
> API in that:
>
>  1. They use the existing external iterator, 

You mean index.

> `iterator.next()`, rather
> than the proposed style, `iterator.next()`, because the new style
> ties the iterator to a particular collection type and therefore
> cannot be type erased.

The new style does not prevent type erasure.  See
https://github.com/apple/swift/blob/swift-3-indexing-model/stdlib/public/core/ExistentialCollection.swift.gyb
for an example.

> Type erasure is required to keep return types generic, e.g. rather than
> map returning an Array it returns an `AnyNextorable` (see point 
> 5 below).
>  2. The protocols are not, in general, heirarchical; instead they are small 
> building blocks at the top level that can be fitted together.
>  3. Protocols are split when a good default implementation cannot be 
> provided, e.g. CountableCollection is seperate because the default of 
> iterating and
> counting the elements is not a good implimentation of count.
>  4. Hierarchies are used for convenience, e.g. ArrayCollection is a 
> convenience protocol that extends base protocols.
>  5. The protocol member's return generic implementations of protocols, e.g. 
> where you might return an Array instead you return an 
> `AnyNextorable`.
> This sidesteps issues with associated types and generics and prevents 
> large type signatures. The downside is that you have comitted to a particular
> interface and therefore lost covariance. When generics are completed 
> hopefully these return types can be replaced with `Any<... where ...>`, e.g. 
> `Any
> `
>  6. LazyNextable is split out seperately so that the semantics of lazy are 
> articulated in the type system. The design of LazyNextable is also compatible
> with adding ParallelLazyNextable in the future.
>  7. The naming of the protocols is one of:
>  1. Xxxable because it is a main behavioural protocol and its main member 
> is xxx, e.g. Nextorable has a main property nextor.
>  2. If in the rare case that a protocol extends another protocol then the 
> new property is prepended, e.g. MutableSubstriptable extends Substriptable
> and the main method added is mutable subscripting.
>  3. If they don't have a main member then they are named after what they 
> are used for, e.g. ArrayCollection defines the members of Array like
> collections. Note name format of XxxCollection.
>  4. AnyXxxx is a type erased implimentation of Xxx, e.g. AnyLazyNextable 
> is an erased LazyNextable.
>  5. Xxxee and xxxee is used for the subject of an action, e.g. Rangee is 
> a collection of methods that a type must impliment to be used in a Range.
>  8. Range has an Int index of 0 to count - 1 and a value of start + index * 
> stride, where start and stride are of type Rangee. Int and Double via 
> extension
> are made Rangees.
>  9. Index, used in Subscriptables, can be any type.

Let's cut to the chase: what problem are you trying to solve, and how
does your proposal address that problem?

-- 
Dave

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

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

[Andrey Tarantsov via swift-evolution]

>> 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 somewhere, etc).
> 
> To be clear, the mistake this warning prevents is the unintentional call
> to a non-mutating method when one thinks one is mutating the receiver.
> This scenario can arise independently of A or B.

Sure. Although if a type only has mutating or non-mutating methods, but not 
both, the mistake will probably be immediately apparent, so the diagnostic 
doesn't win you much (except maybe in a newbie learning environment, which is 
an important use case as well).

A.

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

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

[Joseph Lord via swift-evolution]

> 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-function-parameters.md

+1 seems obvious to me. I suspect the syntax is rarely used anyway.

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

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

[Howard Lovatt via swift-evolution]

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 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 both c[c.firstIndex] and
> c.[c,lastIndex]
> > to fail.
>
> That direction is pretty much a nonstarter with me.  There are *many*
> algorithms that are correct for empty collections without any
> special-case testing, as long as you use half-open ranges.  There's no
> reason to make every algorithm that uses indices test for emptiness
> before proceeding.
>
> See also
>
> https://www.quora.com/Why-are-Python-ranges-half-open-exclusive-instead-of-closed-inclusive
> for philosophical background on why most ranges should be half-open.
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

Re: [swift-evolution] Deprecating Trailing Closures

[Andrey Tarantsov via swift-evolution]

> 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 remove them, they're great.

A.

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

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

[Jacob Bandes-Storch via swift-evolution]

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 currently in the
middle of a move and multiple travel plans, so I can't spearhead this for
another week or two.

Jacob

On Thu, Mar 24, 2016 at 2:23 PM, Kevin Randrup via swift-evolution <
swift-evolution@swift.org> wrote:

> # 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
> RawRepresentable initializer (SO link
> 
> ).
>
> I'm presenting this idea here for discussion and feedback before I write
> up a formal proposal.
>
> # Limits
> Having an allValues method would only be logical for enums which do not
> have associated values. This limits the enum to RawRepresentable enums and
> basic enums (is there a name for an enum without associated values and no
> raw value?).
> I'm working with the assumption that this would only be done with
> RawRepresentable enums but it may be the case that basic enums can be
> included easily.
>
> # Examples
> All examples as source code are available as a gist
> .
>
> enum CommandLineFlag : String {
> case Version = "--version"
> case Help = "--help"
> case Start = "--start"
> }
>
> func displayHelp() {
> print("Available flags\n")
> for flag in CommandLineFlag.allValues {
> print("\(flag): \(flag.rawValue)")
> }
> }
>
>
>
> Representing the structure and implementing UITableViewDataSource methods
> enum RecipeTableViewSection : Int {
> case Header
> case Details
> }
>
> enum RecipeHeaderRow : Int {
> case Name
> case Image
> }
>
> enum RecipeDetailRow : Int {
> case Ingredients
> case Cost
> case PreparationTime
> }
>
> // UITableViewDataSource implementation
> func tableView(tableView: UITableView, numberOfRowsInSection section: Int)
> -> Int {
> switch RecipeTableViewSection(rawValue: section)! {
> case .Header:
> return RecipeHeaderRow.allValues().count
> case .Details:
> return RecipeDetailRow.allValues().count
> }
> }
>
> func numberOfSectionsInTableView(tableView: UITableView) -> Int {
> return RecipeTableViewSection.allValues().count
> }
>
> # Decisions/Questions
>
> 1. Function vs. computed property vs. stored static variable
>
> static func allValues() -> [CommandLineFlag] {
>   return [Version, Help, Start]
> }
>
>
> static var allValues: [CommandLineFlag] {
>   return [Version, Help, Start]
> }
>
> static let allValues = [Version, Help, Start]
>
>
>- Currently leaning towards computed property
>   - Computed property > function - allValues doesn't do anything
>   besides return a value so it doesn't need to be a function
>   - Computed property > stored static variable - Will not increase
>   the memory usage of the program
>   - A change between computed and stored static property would not be
>a source breaking change if it turns out one is better than the other.
>
> 2. Set vs. Array
>
>- Set - There are no duplicate values and RawRepresentable enums
>already conform to Hashable/Equatable.
>- Array - Preserves the cases' declaration order
>
> 3. Should allValues consist of the enum type or RawValue? (CommandLineFlag
> vs. String)
>
>- Strongly learning towards enum type
>- However, either one could be converted to the other and one could
>simply be a computed property of the other.
>
>
> If you have better examples and use cases, I would love to hear about them
> before writing the proposal.
>
>  - Kevin Randrup
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Randrup via swift-evolution]

# 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
RawRepresentable initializer (SO link

).

I'm presenting this idea here for discussion and feedback before I write up
a formal proposal.

# Limits
Having an allValues method would only be logical for enums which do not
have associated values. This limits the enum to RawRepresentable enums and
basic enums (is there a name for an enum without associated values and no
raw value?).
I'm working with the assumption that this would only be done with
RawRepresentable enums but it may be the case that basic enums can be
included easily.

# Examples
All examples as source code are available as a gist
.

enum CommandLineFlag : String {
case Version = "--version"
case Help = "--help"
case Start = "--start"
}

func displayHelp() {
print("Available flags\n")
for flag in CommandLineFlag.allValues {
print("\(flag): \(flag.rawValue)")
}
}



Representing the structure and implementing UITableViewDataSource methods
enum RecipeTableViewSection : Int {
case Header
case Details
}

enum RecipeHeaderRow : Int {
case Name
case Image
}

enum RecipeDetailRow : Int {
case Ingredients
case Cost
case PreparationTime
}

// UITableViewDataSource implementation
func tableView(tableView: UITableView, numberOfRowsInSection section: Int)
-> Int {
switch RecipeTableViewSection(rawValue: section)! {
case .Header:
return RecipeHeaderRow.allValues().count
case .Details:
return RecipeDetailRow.allValues().count
}
}

func numberOfSectionsInTableView(tableView: UITableView) -> Int {
return RecipeTableViewSection.allValues().count
}

# Decisions/Questions

1. Function vs. computed property vs. stored static variable

static func allValues() -> [CommandLineFlag] {
  return [Version, Help, Start]
}


static var allValues: [CommandLineFlag] {
  return [Version, Help, Start]
}

static let allValues = [Version, Help, Start]


   - Currently leaning towards computed property
  - Computed property > function - allValues doesn't do anything
  besides return a value so it doesn't need to be a function
  - Computed property > stored static variable - Will not increase the
  memory usage of the program
  - A change between computed and stored static property would not be a
   source breaking change if it turns out one is better than the other.

2. Set vs. Array

   - Set - There are no duplicate values and RawRepresentable enums already
   conform to Hashable/Equatable.
   - Array - Preserves the cases' declaration order

3. Should allValues consist of the enum type or RawValue? (CommandLineFlag
vs. String)

   - Strongly learning towards enum type
   - However, either one could be converted to the other and one could
   simply be a computed property of the other.


If you have better examples and use cases, I would love to hear about them
before writing the proposal.

 - Kevin Randrup
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

> * 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, optional a are used to express nullability


> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?


> No


> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Followed discussions on swift-evolution



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

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

[Dave Abrahams via swift-evolution]

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)
> }
> }
>
> /*
> example of usage:
>
> for i in (1..<10).by(2) {
> print(i)
> }
> */
> ```


My current thinking is that:

* `for x in 0.0..<3.0 {}` should probably be an error, because 1.0 is
  not the obviously-right stride to use for non-integral numbers.  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.
  
* `for x in (0.0..<20.0).striding(by: 1.3) {}` should work without
  accumulating error

* `for x in 0..<3 {}` should work (obviously; that's the status quo)

* `for x in (0..<20).striding(by: 2)` should work

I think this might also handle the concerns that
https://github.com/apple/swift-evolution/blob/master/proposals/0051-stride-semantics.md
was trying to address.

If I thought extreme concision was important for this application, I'd be
proposing something like 

  for x in 0.0..<20.0//1.3 {}

but personally, I don't, which is why I propose `.striding(by: x)`
rather than simply `.by(x)`, the latter being more open to
misinterpretation.

-- 
Dave

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

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

[Alex Martini via swift-evolution]

> On Mar 24, 2016, at 11:57 AM, Russ Bishop  wrote:
> 
> 
>> 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 rather than NSObject. The use case 
>> for a non-subclass of NSObject is very narrow, but it’s not a needed 
>> restriction.
>> 
>> The unconditionalyBridgeFromObjectiveC function can probably go away. 
>> Calling initializers from the downcasting infrastructure is horrible. If we 
>> need a function, they
>> 
> Was there more to this line of thought? It looks like it got cut off.

Sorry, I didn't have anything else here.  It looks like I didn't finish the 
sentence while typing during the meeting.

If I remember right, the thought was that we can make a function (or maybe a 
closure) that calls the initializer if the surrounding code needs a function.

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

Re: [swift-evolution] Deprecating Trailing Closures

[Howard Lovatt via swift-evolution]

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 swift-evolution <
swift-evolution@swift.org> wrote:

> When I started using Swift I was initially very enthusiastic about
> trailing closures, but I’ve actually kind of gone off them somewhat and I’d
> like to discuss why.
>
> Firstly, here are two ways to write a common example using the .map()
> method:
>
> let foo = myArray.map { $0 + 1 }
> let foo = myArray.map({ $0 + 1 })
>
> It’s tough to say that the first form is any neater than the second, other
> than the second having more brackets. However, the first form is somewhat
> ambiguous, as .map in this case looks like a property rather than a method,
> it also visually looks like a statement, followed by a closure rather than
> the two things logically being related. Of course it’s quick to learn that
> these are related, but for consistency I’m starting to now prefer the use
> of parenthesis in almost all cases.
>
> The other advantage of trailing closures is the omission of the label, but
> trailing closures aren’t strictly necessary for this, as we can already
> omit external labels for parameters if we want to, and the example above
> shows that a trailing closure isn’t necessary for this. The only real
> difference is that the trailing closure form makes a label optional,
> because you can either provide the closure with label in parenthesis (if
> the label is required) or omit it by trailing, like so:
>
> something.someMethod(foo: 1, predicate: { $0 < $1})
> something.someMethod(foo: 1) { $0 < $1}
>
> However this kind of arbitrarily makes the following impossible:
>
> something.someMethod(foo: 1, { $0 < $1 })
>
> With this in mind it seems to me that we might be better served by the
> ability to make external labels optional, as this would allow us to be just
> as succinct, while being completely clear about what is being passed into
> this method.
>
>
> The only real remaining advantage that I see to trailing closures is the
> ability to define pseudo language constructs, for example:
>
> func repeatUntilEmpty(collection:C, @noescape _ body:()
> throws -> Void) rethrows { while !collection.isEmpty { body() } }
> repeatUntilEmpty(myArray) {
> /* Do something over and over until myArray is empty */
> }
>
> Which I think is a pretty uncommon type of structure, but could be useful
> in some specialised situations. To support this though we could easily use
> a new @trailing attribute instead to indicate that the closure can be used
> in this way. My example isn’t very good as I can’t think of a case that
> really, really needs this, but I think they’re probably out there.
>
>
> To summarise, having come down off my initial enthusiasm for trailing
> closures I’m not sure that they really add that much syntactically,
> especially in the most common cases, while actually being a little
> ambiguous looking and adding inconsistency to the language. I think they
> should remain for the less common cases that can really benefit from them,
> but as a feature that is opted into, so that we can go for consistency by
> default.
>
> I’m interested to hear other people’s thoughts.
>


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

Re: [swift-evolution] SetAlgebra naming update

[Erica Sadun via swift-evolution]

> 
> 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 forward a
> proposal for the API shown here:
> 
>  http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
> 
> and to update the guidelines to suggest using the "form" prefix to
> create a verb phrase for a mutating method when the operation is
> fundamentally non-mutating and described by a noun.

I've got to say, I expected to hate this until I clicked the link and saw the 
actual 
proposed syntax. For the most part, it's good: clear and readable.

Not a fan of "subtracting" (would prefer "bySubtracting"). Other than that
really impressed by how this evolved.

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

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

[Richard Ross via swift-evolution]

> * 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 will run into the IOU situation for C (and hopefully eventually 
C++) APIs, that now need to be audited and updated to reflect nullability 
status, which I'd wager that most existing headers *won't* be audited, 
especially on linux.

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 able to do this.

Finally, having nullable UnsafePointers currently is the only way from swift 
code to convert an UnsafePointer to an Int of its raw address, short of using 
another level of indirection:

let rawAddress: Int = UnsafePointer(nil).distanceTo(myPointer)

Unless the other proposal that's in the works to get the raw address of an 
UnsafePointer goes through (which I'm a supporter of), this would remove a very 
important functionality from the swift language, especially when dealing with 
lower level APIs that can take pointers as integers.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?


I think the goal of being able to write safer code is a noble one, and one we 
should strive for overall in the language. However, I don't believe that this 
is enough of an approach, nor is it inherently 'safer' (as nothing stops you 
from creating another invalid pointer that crashes rather than just NULL). 
Unless we plan on having some way to confirm that a pointer is, in fact, valid, 
I think we should leave UnsafePointer in its 'unsafe' state.

> * Does this proposal fit well with the feel and direction of Swift?

I actually think it does. This will provide a swift-ier interface with raw 
pointers (and causing less confusion amongst beginners (who probably shouldn't 
be using UnsafePointer, but still) and improving API contracts). Again, 
however, UnsafePointer, while powerful, is rarely the proper tool for the job, 
and I think should be left in its current state - powerful, but difficult to 
use, to prevent a foot-gun scenario like we see in C++ and references (ask any 
C++ beginner about the lifetime of a reference...)

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I'm actually unsure of any other languages that have explicit nullability on a 
raw pointer type. (Maybe rust has it? I'm not very familiar with rust).

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I've been following the proposal since day 1, and have put a lot of thought 
into it (one of my current projects uses UnsafePointer quite a bit). I'd like 
to think that I did a rather in-depth review of the subject.

If you've made it this far, thanks for reading my thesis on UnsafePointer :)
--
Richard

> On Mar 24, 2016, at 11:00 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 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 important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>   
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution=CwIGaQ=5VD0RTtNlTh3ycd41b3MUw=Ezje1IF3xGXfUMfsj4fBc7oM7BcJys1dhQ6psfXzLMU=_MgWpo4MYLScsGzB9CqrI-eCyzjjkWNyv8hjBeDANw0=HZtE3Eh63CLwxWA4MExIZyp1Dn7CsH2Te9eRrsFZNfE=
>  
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   

Re: [swift-evolution] SetAlgebra naming update

[Howard Lovatt via swift-evolution]

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 names begin with the same root and
are therefore code completion friendly.

On Friday, 25 March 2016, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> 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 forward a
> proposal for the API shown here:
>
>   http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html
>
> and to update the guidelines to suggest using the "form" prefix to
> create a verb phrase for a mutating method when the operation is
> fundamentally non-mutating and described by a noun.
>
> Regards,
>
> --
> Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


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

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

[Dave Abrahams via swift-evolution]

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 > wrote:
 
 I already knew the impossibility of applying such a predicate as “$0 == 3” 
 and I actually couldn’t quite figure out a solution.
>>> 
>>> I thought so, and I don’t think there is a way to do it, my point
>>> was really just that your swift doc comments weren’t clear on that
>>> point, then I went off at a bit of a tangent ;)
>>> 
>> No problem! What I am trying to figure out here is how we should
>> implement the lowerBound and upperBound functions. Should they
>> exactly reflect their C++ counterparts?
>> Anyway, it seems all of our implementations have the same problem,
>> that they cannot be univocally called with any predicate whatsoever,
>> (or at least it seemed to me during some tests with the
>> implementations :) ), so I don’t really know how we should act. I am
>> a little blocked.
>> Does anyone have ideas on how that could work no matter what predicate is 
>> given? Especially, an upperBound() function, which is a little trickier. 
>
> The key is to use a binary predicate (as used in sort and partition)
> instead of a unary predicate. Then you can use the predicate as is for
> lowerBound or with the arguments "reversed" for upperBound. The
> methods would have a similar signature to indexOf—one that just takes
> a value for comparable collections and one that takes a value and a
> predicate.

Having an overload that accepts a binary predicate is certainly a nice
convenience, but the most general formulation takes a unary predicate
that “partitions” the collection, i.e. returns false for the first N
elements of the collection and returns true for the rest.  

IMO it's important to expose the unary predicate version.  Lots of
times, the thing you want to compare against doesn't have the same type
as the elements of the collection.  For example, you might have a
collection of key-value pairs where you just want to compare against the
keys, and you may not even be able to create an instance of the whole
element.  For more on this, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1313.html

-- 
Dave

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

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

[Dave Abrahams via swift-evolution]

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 via swift-evolution 
  wrote:
>
> One minor change to what I've been proposing: Instead of merely
> saying that it's implementation-defined, we should expressly say
> that invoking next() after it has previously returned nil may
> return nil or it may return an implementation-defined value, but
> it should not fatalError() (unless some other GeneratorType
> requirement has been violated). Which is to say, after a
> GeneratorType has returned nil from next(), it should always be
> safe to invoke next() again, it's just up to the particular
> implementation to determine what value I get by doing that.
>
> -Kevin Ballard

 I'm torn about sequences that end with nil and should continue
 always return nil thereafter and
 (pulling a name out of the air) "samples" that may return nil or non-
 nil values over time. I'd prefer there
 to be two distinct contracts between an iterator and another
 construct that may return an implementation-defined
 value after nil.
>>>
>>> If your sequence produces optional values, then the result of its
>>> generator should be double-optional. If next() returns `.some(nil)`,
>>> that would be a nil value in the sequence; if it returns `nil`,
>>> that's the end.
>>>
>>> -Joe
>>
>> The use case I was thinking of was real-world sampling, where there
>> was actually a value available or not.
>> Using double-optionals as a sequence would work for that. Since that
>> approach might be intuitively
>> obvious, maybe should be clarified through documentation?
>
> Double-optionals makes this pattern useless. The whole point of using
> the Generator pattern here is so you can easily process all of the currently-
> available "samples" and then hit nil and stop, and then later when you
> try again you may or may not get more values. Using a generator that
> returns a double-optional value, the generator would never actually
> return nil directly, it would always return a .Some (either .Some(nil)
> or .Some(value)), and at this point there's no reason to be using a
> Generator at all over just having a method that samples it.

I don't see why you can't just create a new Iterator (neé GeneratorType)
for this purpose.

-- 
Dave

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

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

[Howard Lovatt via swift-evolution]

>
>
>
>- 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 struct but type alias is a neater
> solution.
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes, you would naturally expect this to be possible
>
>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> No
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Followed swift-evolution discussions
>


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

[swift-evolution] SetAlgebra naming update

[Dave Abrahams via swift-evolution]

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-Math.html

and to update the guidelines to suggest using the "form" prefix to
create a verb phrase for a mutating method when the operation is
fundamentally non-mutating and described by a noun.

Regards,

-- 
Dave

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

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

[Chris Lattner via swift-evolution]

> 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 
>> > wrote
>> Allow Swift types to provide custom Objective-C representations 
>> 
>> https://github.com/apple/swift-evolution/pull/198 
>> 
>> The associated type could be AnyObject rather than NSObject. The use case 
>> for a non-subclass of NSObject is very narrow, but it’s not a needed 
>> restriction.
>> 
>> The unconditionalyBridgeFromObjectiveC function can probably go away. 
>> Calling initializers from the downcasting infrastructure is horrible. If we 
>> need a function, they
>> 
> Was there more to this line of thought? It looks like it got cut off.
> 
> I would like to unify this to either have the initializers or have the static 
> functions but not both, but I don’t know which is preferred from an 
> implementation perspective. The initializers feel more “Swifty” but moving 
> back to static functions is perfectly workable.

The preference was to just have the initializers, since that is the preferred 
way to express conversions.

>> Implicit conversions. In this proposals, you don’t get implicit conversions. 
>> Have a separate discussion about whether we can get rid of the four types 
>> that have implicit conversion. We see the existing ones as deeply 
>> problematic.
>> 
> The casting was a late addition to allow the user to work around situations 
> where the ObjC API is deficient and to keep the behavior consistent with how 
> other types are bridged. It could be removed if desired but I agree that it 
> should probably be removed from the existing types as well in that case.
> 
> Removing it would unify behavior: conversion happens through initializers, 
> casting through as. That means the example would be more like “let x = 
> SwiftType(SomeObjCType)”. Strings become “let x = String(anNSString)”

Many of us would prefer to reduce the implicit conversions we have today in 
various ways (e.g. I’m a fan of disabling T -> T? promotion in operator 
argument contexts, which would solve a number of weird ?? issues).  The 
existing implicit bridging conversions fall into the same category: it isn’t 
clear if we can eliminate them, but if we could, that would be great for 
predictability and for type checker performance.

Upshot of this is that there doesn’t seem to be a reason for this new feature 
to add new implicit conversions: doing an explicit conversion with “as” seems 
fine.

-Chris

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

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

[Hooman Mehr via swift-evolution]

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 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 
> you feel that this proposal compares to those?
> N/A
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> In-depth study, I ran into a situation where I needed something like this 
> some time ago.
> 
> 
>> On Mar 24, 2016, at 1:54 PM, 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/blob/master/proposals/0048-generic-typealias.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>>  
>> 
>> Reply text
>> 
>> Other replies
>>  What 
>> goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> Doug Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Erica Sadun via swift-evolution]

> 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
>> alice.firstName = "Alice"
> 
> 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
}

func modify(item: T, update: (inout T) -> Void) -> T {
var this = item
update()
return this
}

let carol: Person = modify(john) {
$0.firstName = "Carol"
}

print(carol)


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

Re: [swift-evolution] Catching NSException

[Joe Groff via swift-evolution]

> 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 good way to do that.  
> Currently the only possible way is to via Objective C code that wraps the 
> call in an Objective C style @try/@catch block.  If building a swift 
> framework, this means a separate module, since we can't use bridging headers.
> 
> My quick attempt at a workaround can be seen here: 
> https://github.com/jonbrooks/ObjCTryCatch 
>  and there are other workarounds 
> out there too.  I wondered if there has been any discussion to building 
> something like this into swift directly.  I don't really have any good ideas, 
> but maybe something like
> 
> do {
> objc_try someObjectiveCInstance.methodThatMightRaiseException()
> } catch {
> //error would be an ErrorType that contains info about the exception 
> raised, or the exception itself?
> }
> 
> Any thoughts?

Catching ObjC exceptions is problematic, since Cocoa generally only uses 
exceptions for unrecoverable programmer error situations, and most ObjC code 
does not attempt to clean up resources or maintain invariants in response to 
exceptions unwinding through it. Generally the best answer is restructure your 
code not to cause the exception to be thrown in the first place. There are 
unfortunately some APIs for which that's not possible, but if you must handle 
ObjC exceptions, I'd recommend doing so from ObjC code rather than from Swift.

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

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

[Colin Barrett via swift-evolution]

> 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
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.

+1. It also has the advantage of getting rid of the confusing distinction 
between “private” and “internal”—which is backwards from the usual 
“API/SPI/IPI” terminology.

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

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

[Erica Sadun via swift-evolution]

> 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
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.

I support this for all the enumerated reasons. This is clean, simple, and 
obvious. 
It retains the benefits and avoids the negatives of the parenthesized versions.

One correction: "googlable" not "googable", because that's how pedants roll. 
(cite: https://en.wikipedia.org/wiki/Muphry%27s_law 
)

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

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

[Juan Ignacio Laube via swift-evolution]

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 
you feel that this proposal compares to those?
N/A

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
In-depth study, I ran into a situation where I needed something like this some 
time ago.


> On Mar 24, 2016, at 1:54 PM, 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/blob/master/proposals/0048-generic-typealias.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] Deprecating Trailing Closures

[Erica Sadun via swift-evolution]

> 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 promotes 
>> "language construct"-like 
>> Void calls, avoids compiler parsing issues when chaining (or using "guard", 
>> "if", etc). It lets
>> me know instantly how the closure is used. 
>> 
>> While I was originally reluctant to adopt it, its advantages have become 
>> self-evident over time. 
>> This ends up being slightly wordier, especially in the few cases you need to 
>> use argument labels. 
>> 
>> I think it's worth it.
> 
> That’s a pretty good rule, and I think it’s what I’m now doing myself as 
> well. Any thoughts on whether it should be enforced, though?
> There’s a thread currently about allowing trailing closures within guard 
> etc., but personally I think that that’s a bad idea, and that it may actually 
> be better to head in the opposite direction (use them less), but currently 
> it’s an automatic feature which I’m not sure is a good thing.
> 
> Given your “Rule of Kevin” we could have the a rule for closures as a last 
> parameter that if they have a non-Void return type, they must add a new 
> @trailing attribute, otherwise trailing is implied.
> 
> 
> I realise there’s an argument to be made that it should just be up to linters 
> or personal preference, but I’m concerned that many developers like myself 
> will use trailing closures everywhere they’re permitted because it seems like 
> the right thing to do, and only later start to consider whether it’s a good 
> idea to actually use them in specific cases. But for consistency’s sake I’d 
> say it’s not good to use them except for language construct type calls (like 
> .forEach actually, which I always forget about too), which is where the main 
> advantage lies.

I'm agnostic on enforcement. I'm unthrilled about adding `@trailing`.

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

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

[Colin Barrett via swift-evolution]

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

> On Mar 24, 2016, at 2:00 PM, Chris Lattner  wrote:
> 
> 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 important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Jordan Rose via swift-evolution]

> 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 
>> 
>> Biggest open issue is what to do with UnsafeBufferPointer which has a base 
>> address and a count of the number of elements at that address. The most 
>> common use is to do fast things with an array. The problem is when you have 
>> an empty array.
>> 
>> We have a statically initialized empty array, so this doesn’t apply to 
>> array. But slices and Cocoa arrays can do it.
>> 
>> Half of the use cases are subscripting off of the buffer, so they don’t 
>> actually use the base address. They can’t actually subscript an empty array, 
>> but it’s not a syntax error — the loop is run zero times, so it doesn’t 
>> matter. The other half pass the pointers down to a C API that takes an 
>> address and count.
>> 
>> Someone might expect that the base address doesn’t change when something is 
>> initialized.
>> 
>> We can’t easily use the zero pointer because SIL already uses it for nil. 
>> But there are issues with using the same representation as C to avoid 
>> bridging costs.
>> 
>> We’re mapping two things in C onto one thing in Swift. In C, the buffer 
>> pointer would be __nullable long * and the length is ulong.
>> 
>> Given everything else in the system, it’s more like pointer. We didn’t call 
>> it a buffer because that tends to imply ownership.
>> 
>> Sketching out the state space:
>> 
>> Pointer  Length  Static type
>> null 0   UBP? 
>> valid>= 0UBP  
>> valid< 0 X
>> vull != 0???  
>> This issue would go away if we got rid of the base address on 
>> UnsafeBufferPointer, but that would get rid of a number of valid C 
>> operations like calling memcopy.
>> 
>> It seems like withUnsafeBufferPointer should never produce nil. With that in 
>> mind, why should UnsafeBufferPointer need to?
>> 
>> We do need a properly-aligned “valid” invalid pointer. LLVM makes 
>> assumptions about things being aligned.
>> 
>> Dominant feedback on the list has been for people want something that round 
>> trips cleanly. Making the base address non-optional adds overhead and 
>> removes the ability to round trip.
>> 
>> It’s unfortunate that we don’t have a way to represent in the type system a 
>> buffer pointer that isn’t nullable, from within withUnsafeBufferPointer 
>> which wouldn’t even call its closure if the buffer has a null base address.
>> 
> In my mind UBP is primarily meant to be a collection. In that case, I imagine 
> (nil, 0) as an input wouldn’t necessarily represent a nil UBP? - it could 
> represent an empty UBP. 
> 
> My question is whether a valid pointer, length 0 is a valid UBP or not - I 
> have trouble imagining a API which wants a UBP which would differentiate this 
> value over the (nil, 0) one and not have it either be an abuse of UBP (using 
> it to transport just a pointer and not representing a buffer) or an error. I 
> suspect it actually would be ok to always represent a length 0 UBP as having 
> a nil base address.

I updated the proposal before it got accepted into the queue; the consensus was 
for the "round-trips cleanly" case. A (valid, 0) pair could still represent a 
range to replace in a C API, so canonicalizing to nil might be a bad idea.

You can see the current version here as SE-0055: 
https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
 


Jordan

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

[swift-evolution] Catching NSException

[Jon Brooks via swift-evolution]

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
wraps the call in an Objective C style @try/@catch block.  If building a
swift framework, this means a separate module, since we can't use bridging
headers.

My quick attempt at a workaround can be seen here:
https://github.com/jonbrooks/ObjCTryCatch and there are other workarounds
out there too.  I wondered if there has been any discussion to building
something like this into swift directly.  I don't really have any good
ideas, but maybe something like

do {
objc_try someObjectiveCInstance.methodThatMightRaiseException()
} catch {
//error would be an ErrorType that contains info about the
exception raised, or the exception itself?
}

Any thoughts?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

>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 UnsafeBufferPointer which has a base 
> address and a count of the number of elements at that address. The most 
> common use is to do fast things with an array. The problem is when you have 
> an empty array.
> 
> We have a statically initialized empty array, so this doesn’t apply to array. 
> But slices and Cocoa arrays can do it.
> 
> Half of the use cases are subscripting off of the buffer, so they don’t 
> actually use the base address. They can’t actually subscript an empty array, 
> but it’s not a syntax error — the loop is run zero times, so it doesn’t 
> matter. The other half pass the pointers down to a C API that takes an 
> address and count.
> 
> Someone might expect that the base address doesn’t change when something is 
> initialized.
> 
> We can’t easily use the zero pointer because SIL already uses it for nil. But 
> there are issues with using the same representation as C to avoid bridging 
> costs.
> 
> We’re mapping two things in C onto one thing in Swift. In C, the buffer 
> pointer would be __nullable long * and the length is ulong.
> 
> Given everything else in the system, it’s more like pointer. We didn’t call 
> it a buffer because that tends to imply ownership.
> 
> Sketching out the state space:
> 
> Pointer   Length  Static type
> null  0   UBP?
> valid >= 0UBP
> valid < 0 X
> vull  != 0???
> This issue would go away if we got rid of the base address on 
> UnsafeBufferPointer, but that would get rid of a number of valid C operations 
> like calling memcopy.
> 
> It seems like withUnsafeBufferPointer should never produce nil. With that in 
> mind, why should UnsafeBufferPointer need to?
> 
> We do need a properly-aligned “valid” invalid pointer. LLVM makes assumptions 
> about things being aligned.
> 
> Dominant feedback on the list has been for people want something that round 
> trips cleanly. Making the base address non-optional adds overhead and removes 
> the ability to round trip.
> 
> It’s unfortunate that we don’t have a way to represent in the type system a 
> buffer pointer that isn’t nullable, from within withUnsafeBufferPointer which 
> wouldn’t even call its closure if the buffer has a null base address.
> 
In my mind UBP is primarily meant to be a collection. In that case, I imagine 
(nil, 0) as an input wouldn’t necessarily represent a nil UBP? - it could 
represent an empty UBP.

My question is whether a valid pointer, length 0 is a valid UBP or not - I have 
trouble imagining a API which wants a UBP which would differentiate this value 
over the (nil, 0) one and not have it either be an abuse of UBP (using it to 
transport just a pointer and not representing a buffer) or an error. I suspect 
it actually would be ok to always represent a length 0 UBP as having a nil base 
address.

Alternatively expressing the way I see it in mock data structures:

enum InnerUnsafeBufferPointerRepresentation  {
   case empty
   case some(UnsafePointer, Int) // where Int is always > 0
}

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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 important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager.


What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


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

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

[James Campbell via swift-evolution]

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
}

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 5:41 PM, Carlos Rodríguez Domínguez <
swift-evolution@swift.org> wrote:

> 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 integer type, but expecting the assignment of a “constant” declared
> inside an enum. Of course, this is error prone, it is “old-style”
> programming and very confusing for newcomers. To solve this issue, my
> proposal is to be able to create extensions that promote certain fields
> within a class or struct to enums.
>
> For instance, let’s take these sample C struct and enum:
>
> struct Card {
> int suit;
> int rank;
> };
>
> typedef enum {HEARTS, DIAMONDS, CLUBS, SPADES} CardSuit;
>
> (Note: I understand that above code follows a bad programming practice,
> yet it is widely common)
>
> It should be imported into swift as follows:
>
> struct Card {
> suit:Int
> value:Int
> }
>
> enum CardSuit : Int {
> case Hearts, Diamonds, Clubs, Spades
> }
>
> Now, I propose to be able to create an extension as follows:
>
> extension Card {
> #enumvalue(suit:CardSuit)
> }
>
> From this moment on, the suit field should only receive CardSuit values,
> thus not requiring the use of raw values for assignments.
>
> These extensions should also be of great interest for people using
> CoreData, since it is not possible to declare enums in models. Therefore,
> to declare enums, it is necessary to declare integer values, and then use
> the “unsafe”, “unexpressive" approach explained before.
>
> Note that the proposal intends to only support promotions from integer
> values to enum values, but, for example, it could also be extended to
> string values.
>
> Finally, it could be appropriate to extend this proposal to redeclare
> func’s signatures, in order to promote certain parameters to enum values.
>
> Best,
>
> Carlos.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] struct subtyping

[James Campbell via swift-evolution]

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 ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 5:34 PM, Tino Heth <2...@gmx.de> wrote:

> 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 because this might be the biggest source of confusion with
> struct inheritance:
> As the two "child-structs" don't add new data to their parent, they would
> (technically) be compatible — but this is fragile, so it might be
> preferable to "hide" polymorphism by default, and maybe add an annotation
> to explicitly allow that a sub-struct can be used as its parent type.
> @compatible(Float) struct SpecialFloat: Float...
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Developer via swift-evolution]

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 generic 
enum with associated type "projections".  I'm glad to see that pattern find a 
formal place in the language.

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 
you feel that this proposal compares to those?
This proposal brings Swift up to par with languages that allow any kind of 
"alias"ing of types, whether that be C++ or Haskell [in a cleaner way than the 
former].

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
In-depth study.  I actually took a crack at an implementation a while ago!

~Robert Widmann

2016/03/24 12:54、Douglas Gregor via swift-evolution  
のメッセージ:

> 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/blob/master/proposals/0048-generic-typealias.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
> Reply text
> 
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alex Martini via swift-evolution]

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 especially rough.)

These are informal comments, intended to guide the proposals in directions that 
draw constructive feedback. You are welcome to ignore the feedback, agree with 
it, or disagree with it.  As always, the formal decision doesn't happen until 
after the review period ends.




Make pointer nullability explicit using Optional 

https://github.com/apple/swift-evolution/pull/219 

Biggest open issue is what to do with UnsafeBufferPointer which has a base 
address and a count of the number of elements at that address. The most common 
use is to do fast things with an array. The problem is when you have an empty 
array.

We have a statically initialized empty array, so this doesn’t apply to array. 
But slices and Cocoa arrays can do it.

Half of the use cases are subscripting off of the buffer, so they don’t 
actually use the base address. They can’t actually subscript an empty array, 
but it’s not a syntax error — the loop is run zero times, so it doesn’t matter. 
The other half pass the pointers down to a C API that takes an address and 
count.

Someone might expect that the base address doesn’t change when something is 
initialized.

We can’t easily use the zero pointer because SIL already uses it for nil. But 
there are issues with using the same representation as C to avoid bridging 
costs.

We’re mapping two things in C onto one thing in Swift. In C, the buffer pointer 
would be __nullable long * and the length is ulong.

Given everything else in the system, it’s more like pointer. We didn’t call it 
a buffer because that tends to imply ownership.

Sketching out the state space:

Pointer Length  Static type
null0   UBP? 
valid   >= 0UBP  
valid   < 0 X
vull!= 0???  
This issue would go away if we got rid of the base address on 
UnsafeBufferPointer, but that would get rid of a number of valid C operations 
like calling memcopy.

It seems like withUnsafeBufferPointer should never produce nil. With that in 
mind, why should UnsafeBufferPointer need to?

We do need a properly-aligned “valid” invalid pointer. LLVM makes assumptions 
about things being aligned.

Dominant feedback on the list has been for people want something that round 
trips cleanly. Making the base address non-optional adds overhead and removes 
the ability to round trip.

It’s unfortunate that we don’t have a way to represent in the type system a 
buffer pointer that isn’t nullable, from within withUnsafeBufferPointer which 
wouldn’t even call its closure if the buffer has a null base address.

Allow Swift types to provide custom Objective-C representations 

https://github.com/apple/swift-evolution/pull/198 

The associated type could be AnyObject rather than NSObject. The use case for a 
non-subclass of NSObject is very narrow, but it’s not a needed restriction.

The unconditionalyBridgeFromObjectiveC function can probably go away. Calling 
initializers from the downcasting infrastructure is horrible. If we need a 
function, they

This doesn’t break the ability of the optimizer to reason about what a dynamic 
cast can do. We require that the bridgeable conformance must be in the same 
module as where the type is defined, and we have a white list of things that 
don’t follow that. Ok... but do we want people to expand casting this way? If 
we say no, we should take it away from array and string and dictionary too.

You shouldn’t need implicit conversions — the use case is very narrow, and we 
would rather have things use explicit conversions. The APIs come in with the 
right type; the implementation of the bridged type has to do conversion, but 
its clients don’t have to see that. From the Swift point of view, there won’t 
be any APIs that take the reference type.

Implicit conversions. In this proposals, you don’t get implicit conversions. 
Have a separate discussion about whether we can get rid of the four types that 
have implicit conversion. We see the existing ones as deeply problematic.

Dynamic casts. For example, AnyObject to a bridged value type. The whole reason 
for the dynamic cast infrastructure is to make the reference types irrelevant. 
Should this be using cast syntax or should we have a different type of 
function? It’s hard to describe what as does. It’s magic because you are 
casting AnyObject to a struct — calling it AnyObject doesn’t make a lot of 
sense.

If we have reference counted existentials, we could merge Any and AnyObject.

Resilience concern: you can not add this protocol after the type has been 
published.

SE-0054: Abolish ImplicitlyUnwrappedOptional type 

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

[Douglas Gregor via swift-evolution]

> 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
>>> struct Bar: ObjectiveCBridgeable { }
>>> struct Foo: ObjectiveCBridgeable { }
>>> 
>>> class API {
>>> let foo: Foo
>>> func objCVersionOfAFunction(obj: SomeObjectiveCType) -> 
>>> SomeObjectiveCType {
>>> let x = obj as! Bar
>>> // We've told the compiler which protocol impl to call
>>> return foo as! SomeObjectiveCType
>>> }
>>> }
>>> 
>>> Any problems with this approach? It makes handling the ambiguous or manual 
>>> bridging case relatively straightforward, though there may be objections to 
>>> using casting this way. [Be careful, I still mourn the loss of @conversion 
>>> so I’m biased :)]
>> 
>> 
>> The problem I have with allowing the ambiguity is that you can get weird 
>> behavior if Bar and Foo are in different modules: import just Bar’s module, 
>> and an Objective-C API mentioning SomeObjectiveCType gets bridged as a Bar. 
>> Import just Foo’s module, and an Objective-C API mentioning 
>> SomeObjectiveCType gets bridged as a Foo. Import both, and 
>> SomeObjectiveCType doesn’t get bridged! Now start splitting class 
>> hierarchies among those modules and you get some very inconsistent imports… 
>> that’s why I think this needs to be an error.
>> 
> 
> The rule requiring the Swift and @objc types to be in the same module 
> wouldn’t allow the scenario you describe.

Ah, yes.

> 
> I’m fine to say it’s an error as this isn’t a capability I have any use for 
> and it definitely could cause confusion. The rule could always be relaxed in 
> the future if there’s a convincing case for it. I’ll update the proposal to 
> make it an error again.

I’d rather call it an error and consider relaxing the rule if we find it’s very 
important later on.

- Doug


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

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

[Chris Wagner via swift-evolution]

What is your evaluation of the proposal?
+1, originally I hadn’t seen the value, but ran into wanting this just the 
other day.

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?
Very much so.


If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
NA

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
Pretty brief, read through the proposal early on and was reaching for this 
functionality a few days ago. 



> On Mar 24, 2016, at 9:54 AM, 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/blob/master/proposals/0048-generic-typealias.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

Re: [swift-evolution] Deprecating Trailing Closures

[Erica Sadun via swift-evolution]

> 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 make 
>> custom constructs that feel more like a part of the language.  For example, 
>> I really love this extension for NSLock that I have:
>> 
>> extension NSLock {
>> func protect(action: (Void) -> Void) {
>> self.lock()
>> action()
>> self.unlock()
>> }
>> }
>> 
>> Now, whenever I need to use my lock, I can just do:
>> 
>> peersLock.protect {
>> outputString += "\(self.peers.count) peers:\n"
>> for (_, peer) in self.peers {
>> outputString += "\(peer)\n"
>> }
>> }
>> 
>> To me, it looks cleaner to me to not have this paren dangling around at the 
>> end.  On this one I’d definitely say that if you don’t like it, don’t use 
>> it.  I don’t *think* that you’re forced to use it anywhere.  It’s a hard 
>> sell to take it away from everyone.
>> 
>> - Will
> 
> I’m not proposing to remove them entirely, in fact your lock example is a 
> perfect example of when a trailing closure makes the most sense, as a form of 
> customised language feature. But I’m wondering if perhaps cases like these 
> should be created using an attribute that specifically enables it? e.g- your 
> definition could become:
> 
>   func protect(action: @trailing (Void) -> Void) { … }
> 
> It’s other cases like common usages of .map() and similar methods where I’ve 
> found myself using the closure in its trailing form less and less, and am not 
> as sure if it’s really needed, or may actually be more of a detriment to the 
> language than a benefit.

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 chaining (or using "guard", 
"if", etc). It lets
me know instantly how the closure is used. 

While I was originally reluctant to adopt it, its advantages have become 
self-evident over time. 
This ends up being slightly wordier, especially in the few cases you need to 
use argument labels. 

I think it's worth it.

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

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

[Douglas Gregor via swift-evolution]

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/blob/master/proposals/0048-generic-typealias.md
Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

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

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md
Reply text

Other replies
 What goes 
into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

Doug Gregor

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

Re: [swift-evolution] Deprecating Trailing Closures

[Haravikk via swift-evolution]

> On 24 Mar 2016, at 16:13, William Dillon  wrote:
> 
>> On Mar 24, 2016, at 7:18 AM, Kurt Werle via swift-evolution 
>> > wrote:
>> 
>> Coming from ruby, I'm quite fond of trailing closures.  I couldn't really 
>> give you a concrete reason why - putting them in the ()'s really isn't that 
>> big a deal.  But I'll say that I move them outside every single time...
>> 
>> I will say that your examples are the most trivial possible and that the 
>> more complex the closure (describing context variables and return types, 
>> throws, etc) the uglier it seem to me to put it inside parens.
>> 
> 
> Agree.
> 
> Another thing I like about trailing closures is that it allows me to make 
> custom constructs that feel more like a part of the language.  For example, I 
> really love this extension for NSLock that I have:
> 
> extension NSLock {
> func protect(action: (Void) -> Void) {
> self.lock()
> action()
> self.unlock()
> }
> }
> 
> Now, whenever I need to use my lock, I can just do:
> 
> peersLock.protect {
> outputString += "\(self.peers.count) peers:\n"
> for (_, peer) in self.peers {
> outputString += "\(peer)\n"
> }
> }
> 
> To me, it looks cleaner to me to not have this paren dangling around at the 
> end.  On this one I’d definitely say that if you don’t like it, don’t use it. 
>  I don’t *think* that you’re forced to use it anywhere.  It’s a hard sell to 
> take it away from everyone.
> 
> - Will

I’m not proposing to remove them entirely, in fact your lock example is a 
perfect example of when a trailing closure makes the most sense, as a form of 
customised language feature. But I’m wondering if perhaps cases like these 
should be created using an attribute that specifically enables it? e.g- your 
definition could become:

func protect(action: @trailing (Void) -> Void) { … }

It’s other cases like common usages of .map() and similar methods where I’ve 
found myself using the closure in its trailing form less and less, and am not 
as sure if it’s really needed, or may actually be more of a detriment to the 
language than a benefit.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] struct subtyping

[Haravikk via swift-evolution]

I’m a +1 for this. It would have been ideal for something I coded recently 
where I ended up having to settle for a class hierarchy instead so I could add 
incrementally without polluting the parent types with a ton of extra methods. I 
didn’t actually need the polymorphism, so structs would have been preferable, 
but just not as practical, but with sub-typing I could have had the best of 
both that I really wanted.

> On 21 Mar 2016, at 11:58, 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 the only possible solution, and Dave Abrahams told 
> me in another thread that changing this rule might be considered in the 
> future — so I'll risk getting taunted by the cool kids who are in favor of 
> eliminating all ancient OOP-ideas ;-) and start a discussion.
> 
> I guess most readers know about the low-level problems that arise when we 
> switch from pointers (always the same size) to value types (size may vary), 
> so I'll start with two possibilities for struct subtyping:
> 
> newtype (see https://www.haskell.org/tutorial/moretypes.html 
>  — or just read on if you 
> are scared by Haskell ;-)
> 
> When a subtype does not add any stored properties to its superclass (memory 
> layout doesn't change), there is no difference at the level of object code — 
> only the type checker may stop you from using those two types interchangeably.
> Some use cases:
> - In Cocoa, there is no separate class for (file system) paths; instead, 
> there are some additions to NSString. String doesn't have those abilities, 
> and imho methods like "stringByAppendingPathExtension" deserve a separate 
> Path-struct, so that those special methods don't pollute the method list of 
> String (URL is the future, so that example is somewhat out-of date).
> - You could impose incompatibility on numeric types to ensure that your 
> calculations use correct quantities. Although this can be annoying (Float vs. 
> CGFloat), decorating numbers with quantity/unit could eliminate bugs that had 
> really disastrous consequences in the past.
> - Increased comfort for floating-point math:
> struct CustomDouble: Double
> 
> func == (a: CustomDouble, b: CustomDouble) -> Bool {
>   return abs(a.value - b.value) < 0.01
> }
> (no need to specify tolerance for each comparison)
> 
> Full subtyping
> 
> As long as you don't cross module borders, it wouldn't be that complicated to 
> add inheritance without restrictions.
> imagine you have a "Customer"-type and a "Employee"-type to store personal 
> data (name, address…).
> Those data objects are perfect candidates to be implemented as structs, but 
> they also cry for a "Person"-superclass, so you are forced to either 
> duplicate code, or to implement your objects as reference types.
> 
> In a real proposal, I would include more details on the problems caused by 
> this feature, but I'd like to see some feedback first.
> 
> Best regards,
> Tino
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Haravikk via swift-evolution]

> On 24 Mar 2016, at 15:32, Ross O'Brien via swift-evolution 
>  wrote:
> 
> I agree that 'private' still feels too subjective on its own. It's 
> intuitively 'not public'; it's not intuitively the access term for 
> 'declaration only'.
> 
> I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd 
> just prefer a corresponding scopeprivate or declarationprivate.

This is why I like the idea of declaring private(file), private(module) or 
private(type), as all are a form of privacy as none are available externally, 
but the parameter clarifies in what way they are limited internally, though 
private(type) could be the default if no parameter is given.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Deprecating Trailing Closures

[James Campbell via swift-evolution]

I think the feature should stay but we need community guidelines on when
and when not to use them.

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 4:13 PM, William Dillon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 24, 2016, at 7:18 AM, Kurt Werle via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Coming from ruby, I'm quite fond of trailing closures.  I couldn't really
> give you a concrete reason why - putting them in the ()'s really isn't that
> big a deal.  But I'll say that I move them outside every single time...
>
> I will say that your examples are the most trivial possible and that the
> more complex the closure (describing context variables and return types,
> throws, etc) the uglier it seem to me to put it inside parens.
>
>
> Agree.
>
> Another thing I like about trailing closures is that it allows me to make
> custom constructs that feel more like a part of the language.  For example,
> I really love this extension for NSLock that I have:
>
> extension NSLock {
> func protect(action: (Void) -> Void) {
> self.lock()
> action()
> self.unlock()
> }
> }
>
> Now, whenever I need to use my lock, I can just do:
>
> peersLock.protect {
> outputString += "\(self.peers.count) peers:\n"
> for (_, peer) in self.peers {
> outputString += "\(peer)\n"
> }
> }
>
> To me, it looks cleaner to me to not have this paren dangling around at
> the end.  On this one I’d definitely say that if you don’t like it, don’t
> use it.  I don’t *think* that you’re forced to use it anywhere.  It’s a
> hard sell to take it away from everyone.
>
> - Will
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Deprecating Trailing Closures

[William Dillon via swift-evolution]

> On Mar 24, 2016, at 7:18 AM, Kurt Werle via swift-evolution 
>  wrote:
> 
> Coming from ruby, I'm quite fond of trailing closures.  I couldn't really 
> give you a concrete reason why - putting them in the ()'s really isn't that 
> big a deal.  But I'll say that I move them outside every single time...
> 
> I will say that your examples are the most trivial possible and that the more 
> complex the closure (describing context variables and return types, throws, 
> etc) the uglier it seem to me to put it inside parens.
> 

Agree.

Another thing I like about trailing closures is that it allows me to make 
custom constructs that feel more like a part of the language.  For example, I 
really love this extension for NSLock that I have:

extension NSLock {
func protect(action: (Void) -> Void) {
self.lock()
action()
self.unlock()
}
}

Now, whenever I need to use my lock, I can just do:

peersLock.protect {
outputString += "\(self.peers.count) peers:\n"
for (_, peer) in self.peers {
outputString += "\(peer)\n"
}
}

To me, it looks cleaner to me to not have this paren dangling around at the 
end.  On this one I’d definitely say that if you don’t like it, don’t use it.  
I don’t *think* that you’re forced to use it anywhere.  It’s a hard sell to 
take it away from everyone.

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

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

[Jean-Daniel Dupas via swift-evolution]

> Le 24 mars 2016 à 06:13, Chris Lattner via swift-evolution 
>  a écrit :
> 
> 
> 
> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution 
>  wrote:
>> Per Doug’s email, the core team agrees we should make a change here, but 
>> would like some bikeshedding to happen on the replacement name for private.
> 
> What we do with private setters is orthogonal from this proposal, so I’m 
> going to ignore it in this thread.  After SE-0025 is resolved, it would be 
> great to have another thread/proposal that discusses reskinning private(set) 
> - presumably as just a modifier on the setter.
> 
> Similarly, this proposal has nothing to do with “protected” or any other type 
> based access control, so I don’t delve into that at all either.
> 
> I’ve seen several proposals that seem promising:
> 
> On Mar 14, 2016, at 5:49 PM, James Berry  wrote:
>> I like fileprivate, if that’s the only change. On the other hand, if we want 
>> to consider a broader change, what about:
>> 
>>  private symbol visible within the current declaration 
>> (class, extension, etc).
>>  private(module) symbol visible within the current module.
>>  private(file)   symbol visible within the current file.
> 
> I love how this establishes a family with different levels of access control, 
> and unites them under the idea of "levels of being private”.  I also like how 
> people would commonly only ever write public and private (because 
> “private(module)” is the default, and "private(file)" is obscure).  However, 
> parenthesized modifiers that take a keyword (as opposed to an identifier) are 
> a bit weird and awkward, so it would be nice to avoid them if possible.
> 
> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution 
>  wrote:
>> public
>> private-module
>> private-file
>> private
> 
> This follows the same sort of structure as James’ proposal, without the 
> parens.  It has the same advantages, but trades them with hyphenated decl 
> modifiers.  We don’t do that, but it is a good direction.
> 
> 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
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.
> 
> What do you all think?
> 
> -Chris


I like the way it goes,  but I don’t like the nospacebetweenwords convention. 
module_private and file_private look better IMHO.




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

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

[Ilya Belenkiy via swift-evolution]

The last sentence was meant to be:
Private and public have well defined meaning, we should keep the same
semantics.

Still, this is an edge case. Maybe we can separate it into another proposal.

On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution <
swift-evolution@swift.org> wrote:

> This is why I'd like private to mean exactly that (no nested class should
> get access). Then the meaning is clear: it's as private as it can be :-)
>
> Private and public have well defined meaning. We
> On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I agree that 'private' still feels too subjective on its own. It's
>> intuitively 'not public'; it's not intuitively the access term for
>> 'declaration only'.
>>
>> I'm not opposed to fileprivate and moduleprivate, if we like those terms.
>> I'd just prefer a corresponding scopeprivate or declarationprivate.
>>
>> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <
>> swift-evolution@swift.org> 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
>>> >private
>>> >
>>> > The advantages, as I see them are:
>>> > 1) We keep public and private meaning the “right” and “obvious” things.
>>> > 2) The declmodifiers “read” correctly.
>>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>>> awkward parenthesized keyword approach.
>>> > 4) The unusual ones would be “googable”.
>>> > 5) Support for named submodules could be “dropped in” by putting the
>>> submodule name/path in parens: private(foo.bar.baz) or
>>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>>> natural than putting keywords in parens.
>>> >
>>> > What do you all think?
>>> >
>>> > -Chris
>>> >
>>> >
>>> > ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> I'm not sure my wording will be perfect here, but I will try: I still
>>> believe that private is implied in "module" and "file" and the problem is
>>> in the name of the plain "private" keyword.
>>>
>>> You may say private is obvious, but when you have moduleprivate and
>>> fileprivate, the natural question I ask is "What remaining kind of private
>>> is there?" so private's obviousness is muddied for me when next to
>>> moduleprivate and fileprivate.
>>>
>>> I will say I would prefer these keywords to the proposed parameter
>>> keywords. I just think:
>>>
>>> file -> implies file only
>>> module -> implies module only
>>>
>>> where adding private to them only adds noise (I.e. fileprivate and
>>> moduleprivate)
>>>
>>> Brandon
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Mar 24, 2016, at 10:40 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> This is why I'd like private to mean exactly that (no nested class should get 
> access). Then the meaning is clear: it's as private as it can be :-)

In that case, you want a type-based access control mechanism, not a scope-based 
access control mechanism.  Your proposal that was provisionally accepted is for 
a scope-based mechanism.  

Chris’s request for bikeshedding on names did not include a request to bikeshed 
on semantics.  Any discussion about type-based access control should happen in 
a different thread IMO.

> 
> Private and public have well defined meaning. We 
> On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution 
> > wrote:
> I agree that 'private' still feels too subjective on its own. It's 
> intuitively 'not public'; it's not intuitively the access term for 
> 'declaration only'.
> 
> I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd 
> just prefer a corresponding scopeprivate or declarationprivate.
> 
> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope 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
> >private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> > parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the 
> > submodule name/path in parens: private(foo.bar.baz) or 
> > moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> > natural than putting keywords in parens.
> >
> > What do you all think?
> >
> > -Chris
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> I'm not sure my wording will be perfect here, but I will try: I still believe 
> that private is implied in "module" and "file" and the problem is in the name 
> of the plain "private" keyword.
> 
> You may say private is obvious, but when you have moduleprivate and 
> fileprivate, the natural question I ask is "What remaining kind of private is 
> there?" so private's obviousness is muddied for me when next to moduleprivate 
> and fileprivate.
> 
> I will say I would prefer these keywords to the proposed parameter keywords. 
> I just think:
> 
> file -> implies file only
> module -> implies module only
> 
> where adding private to them only adds noise (I.e. fileprivate and 
> moduleprivate)
> 
> Brandon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[James Berry via swift-evolution]

Thanks, Chris, for summing up and pulling this back together.

I’m +1 on your suggestion of public, moduleprivate, fileprivate, and private.  
I share your feeling of slight awkwardness about the parens in my previous 
suggestion.

As to other’s expressed concerns about smashedlowerkeywords, they don’t bother 
me too much. I prefer consistency here. As an alternative I’d find 
lower_snake_case acceptable, but would like to see it applied consistently, and 
thus also to associatedtype, etc. I don’t like lowerCamelCase for keywords. But 
if I had my druthers it would be to maintain the status quo of smashedlower.

James


> On Mar 23, 2016, at 10:13 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
> 
> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution 
>  wrote:
>> Per Doug’s email, the core team agrees we should make a change here, but 
>> would like some bikeshedding to happen on the replacement name for private.
> 
> What we do with private setters is orthogonal from this proposal, so I’m 
> going to ignore it in this thread.  After SE-0025 is resolved, it would be 
> great to have another thread/proposal that discusses reskinning private(set) 
> - presumably as just a modifier on the setter.
> 
> Similarly, this proposal has nothing to do with “protected” or any other type 
> based access control, so I don’t delve into that at all either.
> 
> I’ve seen several proposals that seem promising:
> 
> On Mar 14, 2016, at 5:49 PM, James Berry  wrote:
>> I like fileprivate, if that’s the only change. On the other hand, if we want 
>> to consider a broader change, what about:
>> 
>>  private symbol visible within the current declaration 
>> (class, extension, etc).
>>  private(module) symbol visible within the current module.
>>  private(file)   symbol visible within the current file.
> 
> I love how this establishes a family with different levels of access control, 
> and unites them under the idea of "levels of being private”.  I also like how 
> people would commonly only ever write public and private (because 
> “private(module)” is the default, and "private(file)" is obscure).  However, 
> parenthesized modifiers that take a keyword (as opposed to an identifier) are 
> a bit weird and awkward, so it would be nice to avoid them if possible.
> 
> On Mar 15, 2016, at 3:39 AM, Thorsten Seitz via swift-evolution 
>  wrote:
>> public
>> private-module
>> private-file
>> private
> 
> This follows the same sort of structure as James’ proposal, without the 
> parens.  It has the same advantages, but trades them with hyphenated decl 
> modifiers.  We don’t do that, but it is a good direction.
> 
> 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
>   private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.
> 
> What do you all think?
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Xiaodi Wu via swift-evolution]

Perhaps internal is valuable here then?
Maybe: public, moduleinternal, fileinternal, private.
Or just: public, internal, fileinternal, private.
Or, more radically: public, internal, internal(#file), private.

On Thu, Mar 24, 2016 at 10:32 AM Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree that 'private' still feels too subjective on its own. It's
> intuitively 'not public'; it's not intuitively the access term for
> 'declaration only'.
>
> I'm not opposed to fileprivate and moduleprivate, if we like those terms.
> I'd just prefer a corresponding scopeprivate or declarationprivate.
>
> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> 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
>> >private
>> >
>> > The advantages, as I see them are:
>> > 1) We keep public and private meaning the “right” and “obvious” things.
>> > 2) The declmodifiers “read” correctly.
>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>> awkward parenthesized keyword approach.
>> > 4) The unusual ones would be “googable”.
>> > 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>> >
>> > What do you all think?
>> >
>> > -Chris
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> I'm not sure my wording will be perfect here, but I will try: I still
>> believe that private is implied in "module" and "file" and the problem is
>> in the name of the plain "private" keyword.
>>
>> You may say private is obvious, but when you have moduleprivate and
>> fileprivate, the natural question I ask is "What remaining kind of private
>> is there?" so private's obviousness is muddied for me when next to
>> moduleprivate and fileprivate.
>>
>> I will say I would prefer these keywords to the proposed parameter
>> keywords. I just think:
>>
>> file -> implies file only
>> module -> implies module only
>>
>> where adding private to them only adds noise (I.e. fileprivate and
>> moduleprivate)
>>
>> Brandon
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Mar 24, 2016, at 10:52 AM, Ilya Belenkiy via swift-evolution 
>  wrote:
> 
> The last sentence was meant to be:
> Private and public have well defined meaning, we should keep the same 
> semantics.
> 
> Still, this is an edge case. Maybe we can separate it into another proposal.

I think any change in semantics should absolutely be a separate proposal.  I 
support scope-based access semantics.  My opinion about other access semantics 
would depend on the details of a specific proposal, but I think there is a very 
high hurdle to clear for introducing any other access semantics.

> 
> On Thu, Mar 24, 2016 at 11:42 AM Ilya Belenkiy via swift-evolution 
> > wrote:
> This is why I'd like private to mean exactly that (no nested class should get 
> access). Then the meaning is clear: it's as private as it can be :-)
> 
> Private and public have well defined meaning. We 
> On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution 
> > wrote:
> I agree that 'private' still feels too subjective on its own. It's 
> intuitively 'not public'; it's not intuitively the access term for 
> 'declaration only'.
> 
> I'm not opposed to fileprivate and moduleprivate, if we like those terms. I'd 
> just prefer a corresponding scopeprivate or declarationprivate.
> 
> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope 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
> >private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> > parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the 
> > submodule name/path in parens: private(foo.bar.baz) or 
> > moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> > natural than putting keywords in parens.
> >
> > What do you all think?
> >
> > -Chris
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> I'm not sure my wording will be perfect here, but I will try: I still believe 
> that private is implied in "module" and "file" and the problem is in the name 
> of the plain "private" keyword.
> 
> You may say private is obvious, but when you have moduleprivate and 
> fileprivate, the natural question I ask is "What remaining kind of private is 
> there?" so private's obviousness is muddied for me when next to moduleprivate 
> and fileprivate.
> 
> I will say I would prefer these keywords to the proposed parameter keywords. 
> I just think:
> 
> file -> implies file only
> module -> implies module only
> 
> where adding private to them only adds noise (I.e. fileprivate and 
> moduleprivate)
> 
> Brandon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] struct subtyping

[James Campbell via swift-evolution]

Would love a way of extending an existing struct as a new type but it not
being related to the struct it extends.

Sort of like a mixin but for structs, so I could have:

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

*___*

*James⎥Head Of CEO*

*ja...@supmenow.com ⎥supmenow.com *

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 24, 2016 at 2:16 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Could we accomplish something similar to `newtype` by making the
> `typealias` declaration more powerful?
> It's the first thing I tried, but afair someone from the Core Team opposed
> extending typealias - and I had to agree that an "alias" should be just a
> synonym.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ilya Belenkiy via swift-evolution]

This is why I'd like private to mean exactly that (no nested class should
get access). Then the meaning is clear: it's as private as it can be :-)

Private and public have well defined meaning. We
On Thu, Mar 24, 2016 at 11:33 AM Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree that 'private' still feels too subjective on its own. It's
> intuitively 'not public'; it's not intuitively the access term for
> 'declaration only'.
>
> I'm not opposed to fileprivate and moduleprivate, if we like those terms.
> I'd just prefer a corresponding scopeprivate or declarationprivate.
>
> On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <
> swift-evolution@swift.org> 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
>> >private
>> >
>> > The advantages, as I see them are:
>> > 1) We keep public and private meaning the “right” and “obvious” things.
>> > 2) The declmodifiers “read” correctly.
>> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
>> awkward parenthesized keyword approach.
>> > 4) The unusual ones would be “googable”.
>> > 5) Support for named submodules could be “dropped in” by putting the
>> submodule name/path in parens: private(foo.bar.baz) or
>> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
>> natural than putting keywords in parens.
>> >
>> > What do you all think?
>> >
>> > -Chris
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> I'm not sure my wording will be perfect here, but I will try: I still
>> believe that private is implied in "module" and "file" and the problem is
>> in the name of the plain "private" keyword.
>>
>> You may say private is obvious, but when you have moduleprivate and
>> fileprivate, the natural question I ask is "What remaining kind of private
>> is there?" so private's obviousness is muddied for me when next to
>> moduleprivate and fileprivate.
>>
>> I will say I would prefer these keywords to the proposed parameter
>> keywords. I just think:
>>
>> file -> implies file only
>> module -> implies module only
>>
>> where adding private to them only adds noise (I.e. fileprivate and
>> moduleprivate)
>>
>> Brandon
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

In Java, the enum type behaves as an abstract class, sealed against the case 
members (which are singleton instance subclasses.)

While Swift enums aren’t discrete types or singletons, it sounds like what you 
would like is the ability to have an enum behave as so - to be able to override 
base (or protocol extension) behavior with a particular enum case, and have 
that translated most likely into a switch statement (most likely - I suppose if 
you are using witness tables it could optimize the switch away)

Actually with a protocol default behavior being overridden with a single enum 
case, this would give you functionality not possible today (referencing that 
protocol extension method)

In Java, I exploit the enum behavior to implement the State design pattern 
quite a bit, but am limited as Java enums are singletons and thus should be 
isolated from state. Swift enums are even more powerful here, but doing this in 
switch statements is a pain for maintainability.

I like the idea

-DW


> On Mar 23, 2016, at 4:13 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> If you've written enums before, you've no doubt noticed the irritating 
> phenomenon of `switch self` being absolutely everywhere. I first discovered 
> this in some of my very first Swift code, code so old we were still using the 
> `T[]` shorthand syntax:
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all: Suit[] { return [ Hearts, Spades, Diamonds, Clubs ] }
> 
>var description: String {
>switch(self) {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
>}
> 
>var isRed: Bool {
>switch(self) {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
>}
> 
> It would be nice if we could somehow eliminate that. I have two suggestions:
> 
> * Implicitly switch on `self` at the top level of a function or accessor (or 
> at least an enum one with top-level `case` statements).
> 
>enum Suit: Int {
>case Hearts, Spades, Diamonds, Clubs
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
> 
>var description: String {
>case .Hearts:
>return "♥️"
>case .Spades:
>return "♠️"
>case .Diamonds:
>return "♦️"
>case .Clubs:
>return "♣️"
>}
> 
>var isRed: Bool {
>case .Hearts, .Diamonds:
>return true
>case .Spades, .Clubs:
>return false
>}
>}
> 
> * Allow you to attach member definitions to particular cases. It would be an 
> error if they didn't all define the same members, unless there was a 
> top-level catchall.
> 
>enum Suit: Int {
>var isRed: Bool { return false }
> 
>case Hearts {
>let description: String { return "♥️" }
>let isRed: Bool { return true }
>}
>case Spades {
>let description: String { return  "♠️" }
>}
>case Diamonds {
>let description: String { return  "♦️" }
>let isRed: Bool { return true }
>}
>case Clubs {
>let description: String { return  "♣️" }
>}
> 
>static var all = [ Hearts, Spades, Diamonds, Clubs ]
>}
> 
> Any thoughts? This has, to be honest, bothered me since approximately the 
> third day I used the language; I'd love to address it sooner or later.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Update the signature of ObjectiveC.autoreleasepool [SR-842]

[Timothy J. Wood via swift-evolution]

> On Mar 23, 2016, at 10:36 PM, Chris Lattner  wrote:
> I understand that Jordan withdrew his objection later (because no overload is 
> required) but it still isn't clear to me that autoreleasepool should return a 
> value.
> 
> Here’s my thought process: autoreleasepool is *intentionally* looking like a 
> statement, not an expression.  Someday I hope it will be possible to 
> break/continue/return/throw out of a closure, and at that point, it will look 
> exactly like a statement.
> 
> The problem with adding a return value for this is that (so far) we don’t 
> allow the same thing to ‘do’, ‘if’, ‘switch’ and other statements.  I’d argue 
> that autoreleasepool should follow as close as possible in do’s footsteps: 
> if/when we decide to expressionize these statements, at that point should we 
> expressionize autoreleasepool to match.

If this is the plan, then I’d agree that adding a return value would not be 
good since it would make that “inlining” more of a breaking change. But, to 
some extent that ship has already sailed:

func f() {
autoreleasepool {
if (somethingWithLotsOfAutoreleasedObjects()) {
return;
}
somethingImportant()
}
}

If `autoreleasepool` is turned into a statement instead of a function, the 
meaning of existing code will silently change in possibly disastrous and hard 
to detect ways. Is there a plan in place to deal with this? The only idea that 
occurs to me would be to leave `autoreleasepool` as is for a transitional time, 
deprecated, and add a statement with a new name. Though, if a newly named 
statement were to be added, then we’re back to being able to leave 
`autoreleasepool` as a function with a return value and error =)

With the `rethrow`/`throws` annotation, the migration would be easier since the 
compiler would catch `try autorelease {...}` as invalid and the extra `try` 
could be removed.

Either way, I’m most interested in the `rethrow`/`throws` annotations since 
passing a value and error back out are most error-prone part, and since it 
isn’t possible to add in a wrapper. The return value would be possible to 
re-add in a wrapper, of course.

-tim

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

Re: [swift-evolution] Deprecating Trailing Closures

[Thorsten Seitz via swift-evolution]

Coming from Smalltalk where there are no native control structures at all, i.e. 
all control structures are built using closures, I'm very used to creating 
control structure-like methods or mini DSLs. For these trailing closures are 
indispensable.
That is also very common in other languages like Ruby or Scala.

(Smalltalk was even better because it has no parenthesis around argument lists 
which allowed for multiple closure arguments looking as nice as trailing 
closures.)

-Thorsten 

> Am 24.03.2016 um 14:57 schrieb Haravikk via swift-evolution 
> :
> 
> When I started using Swift I was initially very enthusiastic about trailing 
> closures, but I’ve actually kind of gone off them somewhat and I’d like to 
> discuss why.
> 
> Firstly, here are two ways to write a common example using the .map() method:
> 
>   let foo = myArray.map { $0 + 1 }
>   let foo = myArray.map({ $0 + 1 })
> 
> It’s tough to say that the first form is any neater than the second, other 
> than the second having more brackets. However, the first form is somewhat 
> ambiguous, as .map in this case looks like a property rather than a method, 
> it also visually looks like a statement, followed by a closure rather than 
> the two things logically being related. Of course it’s quick to learn that 
> these are related, but for consistency I’m starting to now prefer the use of 
> parenthesis in almost all cases.
> 
> The other advantage of trailing closures is the omission of the label, but 
> trailing closures aren’t strictly necessary for this, as we can already omit 
> external labels for parameters if we want to, and the example above shows 
> that a trailing closure isn’t necessary for this. The only real difference is 
> that the trailing closure form makes a label optional, because you can either 
> provide the closure with label in parenthesis (if the label is required) or 
> omit it by trailing, like so:
> 
>   something.someMethod(foo: 1, predicate: { $0 < $1})
>   something.someMethod(foo: 1) { $0 < $1}
> 
> However this kind of arbitrarily makes the following impossible:
> 
>   something.someMethod(foo: 1, { $0 < $1 })
> 
> With this in mind it seems to me that we might be better served by the 
> ability to make external labels optional, as this would allow us to be just 
> as succinct, while being completely clear about what is being passed into 
> this method.
> 
> 
> The only real remaining advantage that I see to trailing closures is the 
> ability to define pseudo language constructs, for example:
> 
>   func repeatUntilEmpty(collection:C, @noescape _ 
> body:() throws -> Void) rethrows { while !collection.isEmpty { body() } }
>   repeatUntilEmpty(myArray) {
>   /* Do something over and over until myArray is empty */
>   }
> 
> Which I think is a pretty uncommon type of structure, but could be useful in 
> some specialised situations. To support this though we could easily use a new 
> @trailing attribute instead to indicate that the closure can be used in this 
> way. My example isn’t very good as I can’t think of a case that really, 
> really needs this, but I think they’re probably out there.
> 
> 
> To summarise, having come down off my initial enthusiasm for trailing 
> closures I’m not sure that they really add that much syntactically, 
> especially in the most common cases, while actually being a little ambiguous 
> looking and adding inconsistency to the language. I think they should remain 
> for the less common cases that can really benefit from them, but as a feature 
> that is opted into, so that we can go for consistency by default.
> 
> I’m interested to hear other people’s thoughts.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brandon Knope via swift-evolution]

> 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
>private
> 
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) The unusual ones (moduleprivate and fileprivate) don’t use the awkward 
> parenthesized keyword approach.
> 4) The unusual ones would be “googable”.
> 5) Support for named submodules could be “dropped in” by putting the 
> submodule name/path in parens: private(foo.bar.baz) or 
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more 
> natural than putting keywords in parens.
> 
> What do you all think?
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I'm not sure my wording will be perfect here, but I will try: I still believe 
that private is implied in "module" and "file" and the problem is in the name 
of the plain "private" keyword. 

You may say private is obvious, but when you have moduleprivate and 
fileprivate, the natural question I ask is "What remaining kind of private is 
there?" so private's obviousness is muddied for me when next to moduleprivate 
and fileprivate. 

I will say I would prefer these keywords to the proposed parameter keywords. I 
just think:

file -> implies file only
module -> implies module only 

where adding private to them only adds noise (I.e. fileprivate and 
moduleprivate)

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

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

[Ross O'Brien via swift-evolution]

I agree that 'private' still feels too subjective on its own. It's
intuitively 'not public'; it's not intuitively the access term for
'declaration only'.

I'm not opposed to fileprivate and moduleprivate, if we like those terms.
I'd just prefer a corresponding scopeprivate or declarationprivate.

On Thu, Mar 24, 2016 at 3:21 PM, Brandon Knope via swift-evolution <
swift-evolution@swift.org> 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
> >private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
> >
> > What do you all think?
> >
> > -Chris
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I'm not sure my wording will be perfect here, but I will try: I still
> believe that private is implied in "module" and "file" and the problem is
> in the name of the plain "private" keyword.
>
> You may say private is obvious, but when you have moduleprivate and
> fileprivate, the natural question I ask is "What remaining kind of private
> is there?" so private's obviousness is muddied for me when next to
> moduleprivate and fileprivate.
>
> I will say I would prefer these keywords to the proposed parameter
> keywords. I just think:
>
> file -> implies file only
> module -> implies module only
>
> where adding private to them only adds noise (I.e. fileprivate and
> moduleprivate)
>
> Brandon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Knothe via swift-evolution]

Well I would love to be able to create and use my own keywords / alphanumeric 
operators.
Depending on the type of code you are writing, these may be more or less 
helpful. The same is true for the 'step' keyword - maybe most people won't ever 
use it - but I think there should certainly be a possiblity, be it a concrete 
keyword built into the language or the possibility to create my own ones.

> Am 24.03.2016 um 12:41 schrieb Haravikk :
> 
> 
>> On 24 Mar 2016, at 08:54, David Knothe  wrote:
>> 
>> I do not think an operator like ..+ is intuitive nor will it make code 
>> easier to read or write.
> 
> While I agree that ..+ isn’t the nicest operator choice, there may be other 
> possibilities. It would be interesting if we could use regular letters as 
> operators, as you could actually just declare your by or step keyword 
> yourself in that way, but it could be specific to strideable ranges, though 
> it may not be worth the chaos of everyone then declaring custom keywords 
> everywhere.
> 
> Personally I don’t see the issue of requiring parenthesis to use (1 ..< 
> 10).by(2), ultimately we’re still just iterating over a sequence, all we want 
> is control over how a range’s sequence is generated, rather than it just 
> using a stride of 1. A keyword is certainly prettier, but I think it’s better 
> that developers know that there’s nothing new going on here, and that it’s 
> still just a regular sequence like any other, rather than introducing a new 
> structure that looks sort of like a new form of loop, but really isn’t.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Mar 24, 2016, at 9:59 AM, Ilya Belenkiy  wrote:
> 
> I am not sure if consistency is a problem here. My primary concern is that as 
> long as the class or extension code itself hasn't changed, it's private API 
> stays hidden from anything else. If we can simply inject a class into a class 
> or extension and get access to all of its internals, that reduces the 
> protection level that private would provide. I'd like private to hide 
> implementation details completely.

That wouldn’t be possible because the semantics are scope-based, not 
type-based.  

Here’s an example (using the new “private” modifier):

fileA.swift:

class C {
private let s: String

class Nested {
func foo() {
let c = C()

// s is visible here because `Nested` and `foo` 
// are within the lexical scope that declared `s`
let s = c.s
}
}
}

extension C {
// `s` is not visible anywhere here
// because we are not within the lexical scope
// where `s` was declared
}

fileB.swift:

extension C {
// `s` is not visible anywhere here
// because we are not within the lexical scope
// where `s` was declared
}

> 
> That said, I am not sure if we need to discuss it as part of this proposal.
> On Thu, Mar 24, 2016 at 10:28 AM Matthew Johnson  > wrote:
> 
> 
> Sent from my iPad
> 
> On Mar 24, 2016, at 8:40 AM, Ilya Belenkiy  > wrote:
> 
>> The discussion was about the other direction: whether a nested class should 
>> have access to private members of the outer class.
> 
> In that case the answer seems clear as well.  Everywhere in Swift's access 
> model nested scopes have visibility to all members visible in the containing 
> scope.  For example, all scopes in a file can see any "fileprivate" members 
> contained in that file.  
> 
> Following this semantic, all nested types would be able to see members of 
> their containing type, even those with the new "private" visibility because 
> the nested types are within the same scope where those members are declared. 
> 
> Semantic consistency is the most important concern IMO.  All current access 
> modifiers are strictly based on nested scopes.  Hiding members of a 
> containing type from a nested type would break this model and introduce 
> type-driven semantics, which I think (and hope) is beyond the scope of this 
> proposal (pun mildly intended).
> 
> Matthew
> 
>> 
>> On Thu, Mar 24, 2016 at 9:35 AM Matthew Johnson > > wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On Mar 24, 2016, at 5:07 AM, Ilya Belenkiy via swift-evolution 
>> > wrote:
>> 
>>> It's very consistent with other keywords. I wish compound keywords were 
>>> joined with a dash or something that made them easier to read, but I guess 
>>> it's too late now. If we have associatedtype, it makes sense to use 
>>> moduleprivate (I saw that the name  associatedtype was discussed 
>>> extensively but didn't participate in the discussion; I am sure that it was 
>>> given a lot of thought). If we could change this, I'd suggest keyword names 
>>> with dashes everywhere, but if not, these names work well and is a great 
>>> compromise for everything I've seen in this thread.
>>> 
>>> I am not worried about the length because the 2 most frequently written 
>>> keywords would be public and private. Moduleprivate is the default, and 
>>> file private will not be used as often as private.
>>> 
>>> One question: should the proposal be explicit about access control for 
>>> nested classes? We discussed it here briefly (I wanted private to be 
>>> completely private to the class or extension itself while 2 other people 
>>> wanted a nested class to have access to the outer class.)
>> 
>> I don't think it would make sense at all to allow an outer type to see 
>> private members of a nested class.  That would break the semantics of 
>> private meaning "containing scope".
>> 
>> However, with Chris's suggestion of using identifiers as parameters, maybe 
>> we could eventually have something like private(OuterTypeName) to specify 
>> the precise level of access desired.
>> 
>>> 
>>> On Thu, Mar 24, 2016 at 1:13 AM Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> On Mar 14, 2016, at 5:18 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> > Per Doug’s email, the core team agrees we should make a change here, but 
>>> > would like some bikeshedding to happen on the replacement name for 
>>> > private.
>>> 
>>> What we do with private setters is orthogonal 

Re: [swift-evolution] Add an ifPresent function to Optional

[David Waite via swift-evolution]

> On Mar 23, 2016, at 3:36 PM, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
>> * Are the current stdlib names for optional map and flatMap misleading?
> 
> Not so much misleading, as being unfortunate when optionals and collections 
> end up as neighbors in the code.
> 
> 
>> * Are the current stdlib functions for optional closure application 
>> appropriate and sufficient?
>> 
>> public func f1(@noescape f: (Wrapped) throws -> U) rethrows -> U?
>> public func f2(@noescape f: (Wrapped) throws -> U!) rethrows -> U!
>> public func f3(@noescape f: (Wrapped) throws -> U) rethrows -> Void
> 
> I don't see why flatMap needs to be separate from map. It just does not make 
> sense. I would only have
> 
> public func f2(@noescape f: (Wrapped) throws -> U?) rethrows -> U?
> 
> and would call it "ifPresent", "then", "unwrap", "transform" or something 
> like that.

Optionals of Optionals are valid, and it would be ambiguous which would be 
returned from a map overloaded to allow both optional and non-optional 
transform functions. So, map always assumes the transform returns a 
non-optional, and if it returns an optional value (and that was not what you 
wanted) you have to flatten. Hence flatMap to combine the two steps.

-DW


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Deprecating Trailing Closures

[Haravikk via swift-evolution]

> On 24 Mar 2016, at 14:18, Kurt Werle  wrote:
> 
> Coming from ruby, I'm quite fond of trailing closures.  I couldn't really 
> give you a concrete reason why - putting them in the ()'s really isn't that 
> big a deal.  But I'll say that I move them outside every single time...
> 
> I will say that your examples are the most trivial possible and that the more 
> complex the closure (describing context variables and return types, throws, 
> etc) the uglier it seem to me to put it inside parens.

Perhaps, but if you’re getting that onto a single line then it starts to look 
ugly regardless IMO, whereas splitting it across multiple lines isn’t really 
any different with or without being in the parenthesis, except that the closing 
parenthesis at least clarifies that it was a method you’re closing, for example:

var modifier = true
let foo = myArray.map({
var result = $0
if modifier { result = -result }

modifier = !modifier
return result
})

I dunno, I guess I’m just struggling to find cases in my own code where they 
really offer much of an advantage to justify having a distinctly different way 
of doing things, with the ambiguity and inconsistency that represents, which is 
why I’ve brought it up to discuss; i.e- do we use them just because they exist? 
Trivial aesthetic difference? Personal preference only?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

[Rainer Brockerhoff via swift-evolution]

(replying on gmane as I see my previous reply lost threading. @#$%^
Thunderbird.)

On 3/24/16 11:31, Stephen Canon via swift-evolution wrote:
>> On Mar 24, 2016, at 10:01 AM, Rainer Brockerhoff  
>> wrote:
>>
>> There's the mismatch between decimal representation of binary formats,
>> causing confusion for very common cases like 0.01. There's your work in
>> upgrading the FloatingPoint protocol. There's the question of
>> modernizing NSDecimalNumber or writing a new decimal type. The
>> scientific community needs IEEE 754, the mathematical community needs
>> exact-precision bignums, the financial community needs predictable but
>> small decimal precision, the educators need simple decimal numbers for
>> teaching and graphing.
>>
>> IMHO the existing Double, Float and CGFloat types don't cover all those
>> use cases.
>>
>> Maybe we need a DecimalLiteralConvertible not as generic as
>> FloatLiteralConvertible, so that we can have a built-in type - call it
>> Decimal or SimpleDecimal - that would be inferred in a statement like
>> `let x = 0.01`
>> such that, thereafter, calculations with x are sufficient for 99% of
>> real-world graphing and financial calculations, with exact comparisons
>> and so forth, but with none of the IEEE 754 complications. (Of course if
>> you need trigonometry and square root etc. just convert to Double.)
> 
> I believe that providing the IEEE 754 “Decimal128” type (plus support
> for decimal literals) would satisfy 99% of the requirements listed
> here (while also conforming to FloatingPoint).  It provides 34
> significant digits (sufficient to represent the US nation debt in
> Zimbabwean dollars).

I now read up on Decimal128 and it looks excellent.

(Anecdote re: Zimbabwean dollars; during the hyperinflation period here
in Brazil we were unable to use any “foreign” home accounting apps, as
they, of course, didn't support millions and billions of currency
properly. Many had no adjustable column widths, even.)

Can I conclude that you intend to introduce this type into Swift, then?
And would it be the default type for decimal literals, as I suggested?

If so, no need for me to update my (pre-)proposal at all.


> Arbitrary-precision integer arithmetic is likely better served by a dedicated 
> big integer type.  Does that seem reasonable?

Indeed, I just mentioned that as a possible side-effect, but I don't
need it myself.

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

[Stephen Canon via swift-evolution]

> On Mar 24, 2016, at 10:01 AM, Rainer Brockerhoff  
> wrote:
> 
> There's the mismatch between decimal representation of binary formats,
> causing confusion for very common cases like 0.01. There's your work in
> upgrading the FloatingPoint protocol. There's the question of
> modernizing NSDecimalNumber or writing a new decimal type. The
> scientific community needs IEEE 754, the mathematical community needs
> exact-precision bignums, the financial community needs predictable but
> small decimal precision, the educators need simple decimal numbers for
> teaching and graphing.
> 
> IMHO the existing Double, Float and CGFloat types don't cover all those
> use cases.
> 
> Maybe we need a DecimalLiteralConvertible not as generic as
> FloatLiteralConvertible, so that we can have a built-in type - call it
> Decimal or SimpleDecimal - that would be inferred in a statement like
> `let x = 0.01`
> such that, thereafter, calculations with x are sufficient for 99% of
> real-world graphing and financial calculations, with exact comparisons
> and so forth, but with none of the IEEE 754 complications. (Of course if
> you need trigonometry and square root etc. just convert to Double.)

I believe that providing the IEEE 754 “Decimal128” type (plus support for 
decimal literals) would satisfy 99% of the requirements listed here (while also 
conforming to FloatingPoint).  It provides 34 significant digits (sufficient to 
represent the US nation debt in Zimbabwean dollars).

Arbitrary-precision integer arithmetic is likely better served by a dedicated 
big integer type.  Does that seem reasonable?

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