Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

[Brent Royal-Gordon via swift-evolution]

> I have a small remark though, wouldn’t it be better to let transform be of 
> type (Key, Value) throws -> T instead of (Value) throws -> T? You can just 
> ignore the key (with _) if you don’t need it, but I think it might come in 
> handy in some cases.

The problem is, that closes the door to writing many simple maps in functional 
style. For instance, this:

dictionaryOfNumbers.mapValues(abs)

Would have to become this:

dictionaryOfNumbers.mapValues { _, v in abs(v) }

(It *might* be possible to do it with `$1`, but I'm not sure; there are some 
limitations around that.)

A value-value map is just simpler and cleaner, while almost always giving you 
what you need.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

[David Sweeris via swift-evolution]

Sorry, I misspoke. I just meant define it like this:
public enum IntegerSign : Int {
case Negative = -1
case Zero = 0
case Positive = 1
public var signum: T {
return T(self.rawValue.toIntMax())
}
}

Although, come to think of it, I’m not sure if that’s an exact drop-in 
replacement for your code, since it’s `SignedIntegerType` instead of 
`SignedNumberType`

-Dave Sweeris

> On May 23, 2016, at 11:48 PM, Charlie Monroe  
> wrote:
> 
> Sure, that's a good idea, though I'd personally use the signum var, since 
> using rawValue seems like a bit of an abuse of the fact the enum is defined 
> this way and doesn't help readability of the code:
> 
> enum IntegerSign: RawRepresentable {
> 
> case Negative
> case Zero
> case Positive
> 
> init?(rawValue: NumberType) {
> if rawValue == -1 {
> self = .Negative
> } else if rawValue == 0 {
> self = .Zero
> } else if rawValue == 1 {
> self = .Positive
> } else {
> return nil
> }
> }
> 
> var rawValue: NumberType {
> return self.signum
> }
> 
> var signum: NumberType {
> switch self {
> case .Negative:
> return -1 as NumberType
> case .Zero:
> return 0 as NumberType
> case .Positive:
> return 1 as NumberType
> }
> }
> 
> }
> 
> extension SignedNumberType {
> var sign: IntegerSign {
> if self == 0 {
> return .Zero
> } else if self > 0 {
> return .Positive
> } else {
> return .Negative
> }
> }
> }
> 
> 
> 
>> On May 24, 2016, at 6:09 AM, David Sweeris > > wrote:
>> 
>> Can we make it RawRepresentable? That way signum can just return 
>> self.rawValue
>> 
>> Sent from my iPhone
>> 
>> On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>>> The clean way would be to make it an enum with var signum that would return 
>>> -1, 0, 1:
>>> 
>>> enum IntegerSign {
>>> 
>>> case Negative
>>> case Zero
>>> case Positive
>>> 
>>> var signum: NumberType {
>>> switch self {
>>> case .Negative:
>>> return -1 as NumberType
>>> case .Zero:
>>> return 0 as NumberType
>>> case .Positive:
>>> return 1 as NumberType
>>> }
>>> }
>>> 
>>> }
>>> 
>>> extension SignedNumberType {
>>> var sign: IntegerSign {
>>> if self == 0 {
>>> return .Zero
>>> } else if self > 0 {
>>> return .Positive
>>> } else {
>>> return .Negative
>>> }
>>> }
>>> }
>>> 
>>> Charlie
>>> 
 On May 23, 2016, at 9:29 AM, Haravikk via swift-evolution 
 > wrote:
 
 Could you give an example of this method’s usage? Surely your value is 
 either positive, negative or zero already, so this method doesn’t return 
 anything more useful.
 
 In other words, anywhere that I might do this:
 
if myValue.sign > 0 { … }
 
 I could just as easily do:
 
if myValue > 0 { … }
 
 To the same end result surely? Unless I’m missing something it seems 
 redundant.
 
 If there is a use-case for this, would it make more sense to have the 
 return type as an enum with cases for Positive, Negative and Zero?
 
> On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution 
> > wrote:
> 
> Howdy,
> I think that the SignedNumberType should implement a method called sign 
> that will return -1 for negative numbers, 0 for 0 and 1 for positive 
> numbers. This is similar to the signum method in e.g. Java and similarly 
> called methods in other languages.
> 
> The implementation is fairly straight forward
> 
> extension SignedNumberType {
>   var sign: Self {
> if self == 0 {
>   return 0
> }
> else if self > 0 {
>   return 1
> }
> return -1
>   }
> } 
> 
> I was trying to implement is without branching by doing (x > 0) - (x < 0) 
> but I couldn't get the types right so I'm open to suggestions.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Brent Royal-Gordon via swift-evolution]

> Earlier e-mail example:
>> let foo = 
>> "positive" where ( bar > 0 )  ?? 
>> "negative" where ( bar < 0 ) ?? 
>> "zero"
> 
> let foo = bar > 0 ? "positive" :
>   bar < 0 ? "negative" :
>   "zero"

See, this just makes me want to remix ternary...

let foo =   (bar > 0) :: "positive" ??
(bar < 0) :: "negative" ??
"zero"

// :: is not actually legal to declare, but notionally...
infix operator :: {
associativity left
precedence 133
}
func :: (lhs: B, rhs: @autoclosure () -> T?) -> T? {
guard lhs else {
return nil
}
return rhs()
}

`::` is an operator which evaluates the condition on the left and returns the 
right if true, or nil otherwise. You can chain `::`s together with the existing 
`??` operator. You can terminate the sequence with a trailing `?? value` to 
ensure you won't get a nil. Or you can leave off the trailing `??`, or even 
omit the chain of `??`s altogether if `::` by itself does what your code needs.

Actually, the main problem I see here is that `??`'s, and therefore `::`'s, 
precedence is too tight—it binds more tightly than the comparison operators. 
One solution might be to put `::` and `??` at their current high precedence, 
but also have `:` and `?` with the same semantics at a precedence level just 
above assignment...

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
 
]
 

Hi, Tony. Thanks for working on this. I have to say I’m incredibly concerned 
with this direction, for two main reasons. I’ll try to break them down here. 
(Sorry for squeaking in at the end of the review period!)

Overrides

People up until now have been fairly unhappy with how operators are statically 
dispatched and can’t be overridden. We went all the way towards providing == 
that automatically calls isEqual(_:) on NSObject, but then you provide == for 
your subclass and it never gets called…no, wait, it does get called when you do 
a simple test, but not from the actual code that has NSObject as a static type.

This proposal stays in that space: the proposed “trampoline” operator will 
dispatch based on the static type of the objects, not the dynamic type. Why? 
Consider using == on an NSURL and an NSString, both statically typed as 
NSObject. Given the definition of the trampoline from the proposal

func == (lhs: T, rhs: T) -> Bool {
  return T.==(lhs, rhs)
}

T can’t possibly be anything but NSObject. (Neither NSURL nor NSString matches 
the types of both ‘lhs’ and ‘rhs’.) This isn’t a regression from the current 
model, as you say, but it does make the current model even more surprising, 
since normally you’d expect methods to be dynamically dispatched.

Here’s an alternate formation of the trampoline that’s a little better about 
this…

func == (lhs: T, rhs: T) -> Bool {
  return lhs.dynamicType.==(lhs, rhs)
}

…but I’m still not convinced. (People are especially likely to get this wrong 
without the trampolines being synthesized.)

One more note: at one point Joe Groff was investigating the idea that 
conformances wouldn’t be inherited onto subclasses, which would mean no more 
implicit ‘required’ initializers. Instead, the compiler would perform most 
operations by upcasting to the base class, and then converting to the protocol 
type or calling the generic function. In this world, T would always be 
NSObject, never a subclass, and we’d have to come up with something else. I 
think this model is still worth investigating and I wouldn’t want to close off 
our options just for the sake of “cleaning house”.

It’s possible that there’s not actually a reason to override operators in 
practice, which would make pretty much all of these concerns go away. (== is 
special; imagine we had an operation for checking equality within types and one 
across type hierarchies and ignore it for now.) I think it’d be worth 
investigating where operators are overridden today, and not just in Swift, to 
make sure we cover those use cases too.

(Please forgive all of the Foundation type examples that may soon be value 
types. They’re convenient.)


Assignment Operators

A mutating requirement and a static method with an inout parameter mean 
different things for a conforming class: the former can only access the class’s 
properties, while the latter can replace the caller’s reference as well.

class Player { … }

extension Player {
  static func roulette(_ player: inout Player) {
if randomValue() > 0.1 {
  player.roundsSurvived += 1
} else {
  // Replace this player…but not any other references to them!
  player = Player()
}
  }

  /*mutating*/ func solitaire() {
self.roundsSurvived += 1
// Cannot replace ‘self’
//self = Player()
  }
}

I’m not sure if one of these is obviously better than the other (more capable 
↔︎ more footgun). I agree with Nicola's point about mutating methods looking 
better than static methods taking an inout parameter, but that probably 
shouldn’t be the ultimate deciding factor.


I know we want to improve type-checker performance, and reducing the number of 
overloads seems like a way to do that, but I’m not convinced it actually will 
in a significant way (e.g. “you can now use ten operators in a chain instead of 
seven” is not enough of a win). It still seems like there ought to be a lot of 
low-hanging fruit in that area that we could easily clear away, like “an 
overload containing a struct type will never match any input but that struct 
type”.

I personally really want to move operators into types, but I want to do it by 
doing member lookup on the type, and fall back to global operators only if 
something can’t be found there. That approach

- also has potential to improve type-checker performance
- also removes operators from the global namespace
- also removes the need for “override points” (implementation methods like 
NSObject.isEqual(_:) and FloatingPoint.isLessThan(_:))

It does privilege the left-hand side of a binary operator, but I think that’s 
acceptable for the operators we’ve seen in practice. (Of course we would need 
real data to back that up.)


I think that about sums up my concerns and my interest in an 

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

[Charlie Monroe via swift-evolution]

In UIKit/Cocoa, there's CGFloat that does pretty much what you're asking (and 
it's pain working with it in Swift, since it's Double on 64-bit computers, 
while Swift defaults to Float, so you need casting all the time)... And I think 
the default behavior of Swift should be similar.

I wouldn't change the type names since Double still is "double precision", I'd 
just prefer changed default behavior...

Charlie

> On May 24, 2016, at 5:39 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On May 23, 2016, at 9:55 PM, Xiaodi Wu > > wrote:
>> 
>> On Mon, May 23, 2016 at 9:40 PM, David Sweeris > > wrote:
>> 
>> Have we (meaning the list in general, not you & me in particular) had this 
>> conversation before? This feels familiar...
>> 
>> It does, doesn't it? I've been reading this list for too long.
> I just checked, and we have! In this very thread! I didn’t realize it was 
> started almost 6 months ago…
> 
> Out of curiosity, are there plans for Swift's IntegerLiteralType & 
> FloatingPointLiteralType when CPUs eventually support 128-bit ints & floats? 
> Will they still evaluate to “Int64" and “Double” by default, or will they 
> become the bigger types?
> 
> - Dave Sweeris
> ___
> 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] [Pitch] Add the sign method to the SignedNumberType protocol.

[Charlie Monroe via swift-evolution]

Sure, that's a good idea, though I'd personally use the signum var, since using 
rawValue seems like a bit of an abuse of the fact the enum is defined this way 
and doesn't help readability of the code:

enum IntegerSign: RawRepresentable {

case Negative
case Zero
case Positive

init?(rawValue: NumberType) {
if rawValue == -1 {
self = .Negative
} else if rawValue == 0 {
self = .Zero
} else if rawValue == 1 {
self = .Positive
} else {
return nil
}
}

var rawValue: NumberType {
return self.signum
}

var signum: NumberType {
switch self {
case .Negative:
return -1 as NumberType
case .Zero:
return 0 as NumberType
case .Positive:
return 1 as NumberType
}
}

}

extension SignedNumberType {
var sign: IntegerSign {
if self == 0 {
return .Zero
} else if self > 0 {
return .Positive
} else {
return .Negative
}
}
}



> On May 24, 2016, at 6:09 AM, David Sweeris  wrote:
> 
> Can we make it RawRepresentable? That way signum can just return self.rawValue
> 
> Sent from my iPhone
> 
> On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution 
> > wrote:
> 
>> The clean way would be to make it an enum with var signum that would return 
>> -1, 0, 1:
>> 
>> enum IntegerSign {
>> 
>> case Negative
>> case Zero
>> case Positive
>>  
>> var signum: NumberType {
>> switch self {
>> case .Negative:
>> return -1 as NumberType
>> case .Zero:
>> return 0 as NumberType
>> case .Positive:
>> return 1 as NumberType
>> }
>> }
>>  
>> }
>> 
>> extension SignedNumberType {
>> var sign: IntegerSign {
>> if self == 0 {
>> return .Zero
>> } else if self > 0 {
>> return .Positive
>> } else {
>> return .Negative
>> }
>> }
>> }
>> 
>> Charlie
>> 
>>> On May 23, 2016, at 9:29 AM, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> Could you give an example of this method’s usage? Surely your value is 
>>> either positive, negative or zero already, so this method doesn’t return 
>>> anything more useful.
>>> 
>>> In other words, anywhere that I might do this:
>>> 
>>> if myValue.sign > 0 { … }
>>> 
>>> I could just as easily do:
>>> 
>>> if myValue > 0 { … }
>>> 
>>> To the same end result surely? Unless I’m missing something it seems 
>>> redundant.
>>> 
>>> If there is a use-case for this, would it make more sense to have the 
>>> return type as an enum with cases for Positive, Negative and Zero?
>>> 
 On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution 
 > wrote:
 
 Howdy,
 I think that the SignedNumberType should implement a method called sign 
 that will return -1 for negative numbers, 0 for 0 and 1 for positive 
 numbers. This is similar to the signum method in e.g. Java and similarly 
 called methods in other languages.
 
 The implementation is fairly straight forward
 
 extension SignedNumberType {
   var sign: Self {
 if self == 0 {
   return 0
 }
 else if self > 0 {
   return 1
 }
 return -1
   }
 } 
 
 I was trying to implement is without branching by doing (x > 0) - (x < 0) 
 but I couldn't get the types right so I'm open to suggestions.
 
 
 ___
 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] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

[Jed Lewison via swift-evolution]

The proposal also suggests:

extension _ObjectiveCBridgeable {
init?(bridging object: AnyObject)
}

Which would yield:

let foo: AnyObject = NSString(string: "String")
let bar = String(bridging: foo) // “String"

let foo2: AnyObject = NSArray(array: [])
let bar2 = String(bridging: foo) // nil

The code in the proposal works OOB in Swift 2.2 for String/Double/Float, but 
not Array and Dictionary. Not sure if it already would work in Swift 3.0 for 
that, or there would need to be a little more work done.

> On May 23, 2016, at 8:22 PM, Jordan Rose  wrote:
> 
> Let’s see…
> 
> let name = plist[“name”].bridge() as String
> 
> Not the worst, but definitely better than any of the alternatives below. 
> Unfortunately, I think that “if” is out of the question, at least for Swift 3.
> 
> Jordan
> 
>> On May 23, 2016, at 20:21, Jed Lewison > > wrote:
>> 
>> If we could have extensions on AnyObject, a simple .bridge() would do the 
>> trick, right? (Assuming bridge was generic.) I think something along those 
>> lines was mentioned in the proposal.
>> 
>> Sent from my iPhone
>> 
>> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>>> I am way late, but I share Brent’s concerns. I don’t think this addresses 
>>> the very common case of “getting a String out of a heterogeneous 
>>> dictionary”.
>>> 
>>> let name = plist[“name”] as! String
>>> 
>>> becomes one of these:
>>> 
>>> let name = plist[“name”] as! NSString as String
>>> let name = String(plist[“name”] as! NSString)
>>> let name = String(forceBridging: plist[“name”]) // not in the proposal
>>> 
>>> none of which I’m particularly happy with. 
>>> 
>>> Jordan
>>> 
>>> 
 On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
>   * What is your evaluation of the proposal?
 
 The review is technically over, but I don't believe a decision has been 
 announced yet, so...
 
 I am generally in favor, but I have a serious concern about the 
 readability of certain conversions with this change. To wit, conversions 
 like these:
 
myArray as! [NSView]
myDictionary as! [String: NSView]
 
 Are about to become something more like these:
 
[NSView](forcedLazyBridging: myArray)
[String: NSView](forcedLazyBridging: myDictionary)

 Or these:
 
Array(forcedLazyBridging: myArray)
Dictionary(forcedLazyBridging: myDictionary)
 
 Either option is a significant regression in code readability compared to 
 the status quo.
 
 It's enough to make me wonder if we shouldn't have special-cased 
 conversion methods for NSArray, NSDictionary, and NSSet:
 
myArray.of(NSView)  // returns [NSView]
myDictionary.of(NSView, for: String)// returns [String: NSView]
mySet.of(NSView)// returns 
 Set
 
 On the other hand, if you *don't* have to specify an element type, these 
 aren't so bad:
 
Array(forcedLazyBridging: myArray)
Dictionary(forcedLazyBridging: myDictionary)
 
 And it gets even better if you use something a little saner than 
 `forcedLazyBridging` for the label.
 
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
 
 Yes. Conversions are a mess, and it'll be nice to clean them up.
 
>   * 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?
 
 Most languages I've used have had much simpler cast systems with nothing 
 particularly close to Swift's bridging casts.
 
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
 
 Quick reading.
 
 -- 
 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Charles Constant via swift-evolution]

Right... per "[swift-evolution] [Idea] Find alternatives to `switch self`"
 it was only "impossible" in my head.

Thanks Dany

This proposal is unnecessary.

On Mon, May 23, 2016 at 8:53 PM, char...@charlesism.com <
charlesism@gmail.com> wrote:

> I'm not actually familiar with the term "tri op" but if you're referring
> to the ternary, it's only useful when you two, or three items.
>
> If you chain a ternary to use more than three options it becomes
> error-prone and almost impossible for a human to read
>
> When I'm at my desktop I'll add a couple better examples of what I'm
> proposing.
>
> Sent from my iPhone
>
> On May 23, 2016, at 6:18 PM, Dany St-Amant  wrote:
>
>
> Why reinvent the wheel, when the old trusty (but a bit cryptic according
> to some) tri-op can do the trick…
>
> Le 23 mai 2016 à 04:29, Charles Constant via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Here's a few examples of what this change would allow.
>
> I just plucked the first instances of other people's switch statements
> that I found on GitHub.
>
> If there were an easy way to search GitHub for chained ternary
> expressions, I would have added some examples of those too, since they
> could all be improved with this where clause + ??.
>
>
> mutating func toggle() {
> switch self{
> case Off:
> self = On
> case On:
> self = Off
> }
> }
>
>
>
> mutating func toggle() {
> self = .On where (self == .Off) ?? .Off
> }
>
>
> mutating func toggle() { self = self == .Off ? .On : .Off }
>
>
> switch switchNumberThree {
> case 10, 11, 12:
> println("It is \(switchNumberThree)")
> default:
> ("It is none of them!")
> }
>
>
> println(
> "It is \(switchNumberThree)" where 10...12 ~= switchNumberThree
> ?? "It is none of them!"
> )
>
>
> print( 10...12 ~= switchNumberThree ? "It is \(switchNumberThree)"
>: "It's none of them" )
>
>
> switch x {
> case 1:
> j++
> case 2:
> j++
> case 3:
> j++
> case 4:
> j++
> fallthrough
> case 5:
> j++
> fallthrough
> default:
> j++
> }
>
>
> j = j+1 where (4...5 ~= x) ?? j+2
>
>
> Broken conversion:
> j += 4...5 ~= x ? 1 : 2
>
> Proper conversion:
> j += 4 ~= x ? 3 : 5 ~= x ? 2 : 1
>
> Earlier e-mail example:
>
> *let foo = *
> *"positive" where ( bar > 0 )  ?? *
> *"negative" where ( bar < 0 ) ?? *
> *"zero"*
>
>
> let foo = bar > 0 ? "positive" :
>   bar < 0 ? "negative" :
>   "zero"
>
> Dany
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

[David Sweeris via swift-evolution]

> On May 18, 2016, at 18:07, plx via swift-evolution 
>  wrote:
> 
> How hard would it be to e.g. simply allow something like this:
> 
>  func ==(lhs: T, rhs: T) -> Bool {
>return lhs T.== rhs
>  }
> 
> …instead of the `T.==(lhs,rhs)` syntax?

Yeah, I've been meaning to suggest that. And 'T.++(x)' and '(x)T.++' for prefix 
and postfix, respectfully.

- Dave Sweeris
___
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`

[Charles Constant via swift-evolution]

Good grief. I think you're right.

Some how, a long time ago, I got it into my head that the order in which
each part of the ternary got evaluated would cause problems for this kind
of thing.

I've had a huge blindspot and I've been railing on the list for something I
don't need for weeks.

Wow, I couldn't be more embarassed.

But I'm happy too, because I can go ahead and just use a chained ternary.

Sorry all, and thanks.


On Mon, May 23, 2016 at 6:26 PM, Dany St-Amant  wrote:

>
> Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I wrote some code tonight to experiment with this kind of thing. I
> apologize if it's off-topic for the thread, but it might be useful to
> others who want to experiment.
>
>
>
> //: Playground - noun: a place where people can play
>
> import Cocoa
>
> infix operator • { precedence 180 }
> infix operator → { associativity left precedence 70 }
> infix operator … { associativity right precedence 60 }
>
> func → ( lhs: Bool, rhs: T ) -> T? {
> return lhs ? rhs : nil
> }
>
> func … ( lhs:T?, rhs:T ) -> T {
> return lhs != nil ? lhs! : rhs
> }
>
> func depends( dep:I, _ closure: (I)->(O) ) -> O {
> return closure( dep )
> }
>
> func • ( lhs: I, rhs: (I)->(O) ) -> O {
> return depends( lhs, rhs )
> }
>
> /* Example using "depends" */
>
> let
> str:String,
> i = 7
>
> str = depends( i ){
> $0==2 → "two" …
> $0==3 → "three" …
> $0==4 → "four" …
> "other"
> }
>
>
> Hmm… replacing -> by ?, and … by : you get:
>
> str = depends( i ){
> $0==2 ? "two" :
> $0==3 ? "three" :
> $0==4 ? "four" :
> "other"
> }
>
> which work as is without a need to define new operators.
>
> Dany
>
> /* Example using "•" operator as "depends" */
>
> enum People { case Kurtz, Popescu, Lime, Martins }
> enum Order { case First, Second, Third, Unknown }
>
> let
> order:Order,
> person:People = .Lime
>
> order = person • {
> $0 == .Kurtz → .First …
> $0 == .Popescu → .Second …
> $0 == .Lime → .Third …
> .Unknown
> }
>
>
> I also have some trepidation about posting it here, because it might have
> bugs. I wans't sure what "precedence" and "associativity" should be, for
> example. But it does make it more convenient to test alternative characters
> for operators, etc.
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On 09.04.2016 9:31, Brent Royal-Gordon wrote:
>>
>>> This design is still very much under development—it hasn't even been
>>> reviewed, let alone added to the language. Here's the draft proposal:<
>>> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>>> >
>>>
>>> I'm not saying that this will necessarily be a solution that ends up
>>> being accepted—I'm merely saying that yes, it's something people are
>>> thinking about and designing; it's just been inactive for a few weeks.
>>>
>>
>> Oh, I see. Thank you for letting know. Just missed "you would be able" in
>> your previous message, did read it as "you are able", so was trying to find
>> this in current Swift version. OK, glad to know that most likely we'll have
>> improvements in enums eterations for Swift 3.0.
>>
>> ___
>> 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] [Pitch] Add the sign method to the SignedNumberType protocol.

[David Sweeris via swift-evolution]

Can we make it RawRepresentable? That way signum can just return self.rawValue

Sent from my iPhone

> On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution 
>  wrote:
> 
> The clean way would be to make it an enum with var signum that would return 
> -1, 0, 1:
> 
> enum IntegerSign {
> 
> case Negative
> case Zero
> case Positive
>   
> var signum: NumberType {
> switch self {
> case .Negative:
> return -1 as NumberType
> case .Zero:
> return 0 as NumberType
> case .Positive:
> return 1 as NumberType
> }
> }
>   
> }
> 
> extension SignedNumberType {
> var sign: IntegerSign {
> if self == 0 {
> return .Zero
> } else if self > 0 {
> return .Positive
> } else {
> return .Negative
> }
> }
> }
> 
> Charlie
> 
>> On May 23, 2016, at 9:29 AM, Haravikk via swift-evolution 
>>  wrote:
>> 
>> Could you give an example of this method’s usage? Surely your value is 
>> either positive, negative or zero already, so this method doesn’t return 
>> anything more useful.
>> 
>> In other words, anywhere that I might do this:
>> 
>>  if myValue.sign > 0 { … }
>> 
>> I could just as easily do:
>> 
>>  if myValue > 0 { … }
>> 
>> To the same end result surely? Unless I’m missing something it seems 
>> redundant.
>> 
>> If there is a use-case for this, would it make more sense to have the return 
>> type as an enum with cases for Positive, Negative and Zero?
>> 
>>> On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution 
>>>  wrote:
>>> 
>>> Howdy,
>>> I think that the SignedNumberType should implement a method called sign 
>>> that will return -1 for negative numbers, 0 for 0 and 1 for positive 
>>> numbers. This is similar to the signum method in e.g. Java and similarly 
>>> called methods in other languages.
>>> 
>>> The implementation is fairly straight forward
>>> 
>>> extension SignedNumberType {
>>>   var sign: Self {
>>> if self == 0 {
>>>   return 0
>>> }
>>> else if self > 0 {
>>>   return 1
>>> }
>>> return -1
>>>   }
>>> } 
>>> 
>>> I was trying to implement is without branching by doing (x > 0) - (x < 0) 
>>> but I couldn't get the types right so I'm open to suggestions.
>>> 
>>> 
>>> ___
>>> 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] [Review] SE-0091: Improving operator requirements in protocols

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md
 
]

Some comments on Nicola’s points (my own comments to come separately):

> 
> 2) The method signatures in the examples are not up to date with the current
> Swift 3 syntax. For example:
> 
> protocol Equatable {
>  static func ==(lhs: Self, rhs: Self) -> Bool
> }
> 
> should be:
> 
> protocol Equatable {
>  static func ==(_ lhs: Self, _ rhs: Self) -> Bool
> }


Operator functions (and subscript indexes) implicitly have no argument labels 
today, so this isn’t technically wrong. You can see that there are no labels 
when you use the functions like, well, functions:

func test(input: Int) { print(input) }
(test)(2) // error: missing argument label 'input:' in call
(+)(2, 3) // okay

It may be worth changing, though.

> 
> 4) I don't agree with the request to limit to static methods for the
> operator implementations.
> I support this for symmetrical binary operators like +, but there are other
> operators like += that seem to work better with members. That is, the
> proposed declaration:
> 
> static func +=(_ lhs: inout Self, _ rhs: Self)
> 
> is more similar to the global += operator definition, but is less clear than:
> 
> mutating func +=(_ rhs: Self)
> 
> this is apparent also at the call site. With the proposed syntax, one would
> need to do:
> 
> func +=(_ lhs: inout T, _ rhs: T) {
>T.+=(lhs, rhs)
> }
> 
> while with a member function this would read more naturally as:
> 
> func +=(_ lhs: inout T, _ rhs: T) {
>lhs.+=(rhs)
> }

I strongly agree with this for assignment operators, and I also think it’s 
important for things that make sense to override in a subclass. However, it 
then puts prefix and postfix operators right back in the space of needing a 
keyword instead of using argument label.


> 
> 5) the proposal mentions the open question of ambiguities between the dot
> syntax to access methods and operators whose name starts with a dot.
> This seems to be a real issue: I don't think
> 
> return T(minimum, maximum)
> 
> looks any good, even if the compiler was able to parse it.
> 
> However, this just means that the methods used to implement operators with
> problematic names would need to use different names. Arguably, the only
> cases where one would really want to use methods with operator names is for
> arithmetical operators. Custom operators like ... are better expressed as
> methods with more significant names.

Backtick escaping could help with this as well:

return T.`…`(minimum, maximum)

It’s still not great but it’s at least less of a soup.

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

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

[David Sweeris via swift-evolution]

> On May 23, 2016, at 9:55 PM, Xiaodi Wu  wrote:
> 
> On Mon, May 23, 2016 at 9:40 PM, David Sweeris  > wrote:
> 
> Have we (meaning the list in general, not you & me in particular) had this 
> conversation before? This feels familiar...
> 
> It does, doesn't it? I've been reading this list for too long.
I just checked, and we have! In this very thread! I didn’t realize it was 
started almost 6 months ago…

Out of curiosity, are there plans for Swift's IntegerLiteralType & 
FloatingPointLiteralType when CPUs eventually support 128-bit ints & floats? 
Will they still evaluate to “Int64" and “Double” by default, or will they 
become the bigger types?

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

[Jordan Rose via swift-evolution]

Let’s see…

let name = plist[“name”].bridge() as String

Not the worst, but definitely better than any of the alternatives below. 
Unfortunately, I think that “if” is out of the question, at least for Swift 3.

Jordan

> On May 23, 2016, at 20:21, Jed Lewison  wrote:
> 
> If we could have extensions on AnyObject, a simple .bridge() would do the 
> trick, right? (Assuming bridge was generic.) I think something along those 
> lines was mentioned in the proposal.
> 
> Sent from my iPhone
> 
> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
>> I am way late, but I share Brent’s concerns. I don’t think this addresses 
>> the very common case of “getting a String out of a heterogeneous dictionary”.
>> 
>> let name = plist[“name”] as! String
>> 
>> becomes one of these:
>> 
>> let name = plist[“name”] as! NSString as String
>> let name = String(plist[“name”] as! NSString)
>> let name = String(forceBridging: plist[“name”]) // not in the proposal
>> 
>> none of which I’m particularly happy with. 
>> 
>> Jordan
>> 
>> 
>>> On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
* What is your evaluation of the proposal?
>>> 
>>> The review is technically over, but I don't believe a decision has been 
>>> announced yet, so...
>>> 
>>> I am generally in favor, but I have a serious concern about the readability 
>>> of certain conversions with this change. To wit, conversions like these:
>>> 
>>> myArray as! [NSView]
>>> myDictionary as! [String: NSView]
>>> 
>>> Are about to become something more like these:
>>> 
>>> [NSView](forcedLazyBridging: myArray)
>>> [String: NSView](forcedLazyBridging: myDictionary)
>>> 
>>> Or these:
>>> 
>>> Array(forcedLazyBridging: myArray)
>>> Dictionary(forcedLazyBridging: myDictionary)
>>> 
>>> Either option is a significant regression in code readability compared to 
>>> the status quo.
>>> 
>>> It's enough to make me wonder if we shouldn't have special-cased conversion 
>>> methods for NSArray, NSDictionary, and NSSet:
>>> 
>>> myArray.of(NSView)  // returns [NSView]
>>> myDictionary.of(NSView, for: String)// returns [String: NSView]
>>> mySet.of(NSView)// returns 
>>> Set
>>> 
>>> On the other hand, if you *don't* have to specify an element type, these 
>>> aren't so bad:
>>> 
>>> Array(forcedLazyBridging: myArray)
>>> Dictionary(forcedLazyBridging: myDictionary)
>>> 
>>> And it gets even better if you use something a little saner than 
>>> `forcedLazyBridging` for the label.
>>> 
* Is the problem being addressed significant enough to warrant a change 
 to Swift?
>>> 
>>> Yes. Conversions are a mess, and it'll be nice to clean them up.
>>> 
* 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?
>>> 
>>> Most languages I've used have had much simpler cast systems with nothing 
>>> particularly close to Swift's bridging casts.
>>> 
* How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
>>> 
>>> Quick reading.
>>> 
>>> -- 
>>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

[Jed Lewison via swift-evolution]

If we could have extensions on AnyObject, a simple .bridge() would do the 
trick, right? (Assuming bridge was generic.) I think something along those 
lines was mentioned in the proposal.

Sent from my iPhone

> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I am way late, but I share Brent’s concerns. I don’t think this addresses the 
> very common case of “getting a String out of a heterogeneous dictionary”.
> 
> let name = plist[“name”] as! String
> 
> becomes one of these:
> 
> let name = plist[“name”] as! NSString as String
> let name = String(plist[“name”] as! NSString)
> let name = String(forceBridging: plist[“name”]) // not in the proposal
> 
> none of which I’m particularly happy with. 
> 
> Jordan
> 
> 
>>> On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> * What is your evaluation of the proposal?
>> 
>> The review is technically over, but I don't believe a decision has been 
>> announced yet, so...
>> 
>> I am generally in favor, but I have a serious concern about the readability 
>> of certain conversions with this change. To wit, conversions like these:
>> 
>>  myArray as! [NSView]
>>  myDictionary as! [String: NSView]
>> 
>> Are about to become something more like these:
>> 
>>  [NSView](forcedLazyBridging: myArray)
>>  [String: NSView](forcedLazyBridging: myDictionary)
>>  
>> Or these:
>> 
>>  Array(forcedLazyBridging: myArray)
>>  Dictionary(forcedLazyBridging: myDictionary)
>> 
>> Either option is a significant regression in code readability compared to 
>> the status quo.
>> 
>> It's enough to make me wonder if we shouldn't have special-cased conversion 
>> methods for NSArray, NSDictionary, and NSSet:
>> 
>>  myArray.of(NSView)  // returns [NSView]
>>  myDictionary.of(NSView, for: String)// returns [String: NSView]
>>  mySet.of(NSView)// returns 
>> Set
>> 
>> On the other hand, if you *don't* have to specify an element type, these 
>> aren't so bad:
>> 
>>  Array(forcedLazyBridging: myArray)
>>  Dictionary(forcedLazyBridging: myDictionary)
>> 
>> And it gets even better if you use something a little saner than 
>> `forcedLazyBridging` for the label.
>> 
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes. Conversions are a mess, and it'll be nice to clean them up.
>> 
>>> * 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?
>> 
>> Most languages I've used have had much simpler cast systems with nothing 
>> particularly close to Swift's bridging casts.
>> 
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> Quick reading.
>> 
>> -- 
>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

[Jordan Rose via swift-evolution]

> On May 23, 2016, at 13:10, Антон Жилин via swift-evolution 
>  wrote:
> 
> @CoreTeam Please, don't forget to merge pull request with fixes and 
> alternatives from review period.
> 
> @AnyoneElse Today is (formally) the last day of review. It may be your last 
> chance!
> 
> Apple repo link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>  
> 
> 
> My repo with some latest changes:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>  
> 

Thanks for doing this. While I’m a little apprehensive about the 
implementation, I don’t expect it to be a problem in practice; a DAG is a 
pretty safe data structure, and the size of the graph (i.e. the number of 
precedence groups in a program) probably won’t be that big in practice. And 
it’s so much better than arbitrary precedence numbers.

To discuss later: what are the naming guidelines for precedence groups? (What 
part of speech? Why UpperCamelCase?) Are they in a separate scope from normal 
names? Can you qualify them with module names?

(Operator declarations in general are weirdly global right now, because they 
need to be resolvable without doing full lookup work, and because it was easier 
to implement them that way. So making precedence groups special as well is 
probably fine, at least for now.)

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

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

[Xiaodi Wu via swift-evolution]

On Mon, May 23, 2016 at 9:40 PM, David Sweeris  wrote:

> On May 23, 2016, at 8:18 PM, Xiaodi Wu  wrote:
> >
> > Int is the same size as Int64 on a 64-bit machine but the same size as
> Int32 on a 32-bit machine. By contrast, modern 32-bit architectures have
> FPUs that handle 64-bit and even 80-bit floating point types. Therefore, it
> does not make sense for Float to be Float32 on a 32-bit machine, as would
> be the case in one interpretation of what it means to mirror naming
> "conventions." However, if you interpret the convention to mean that Float
> should be the largest floating point type supported by the FPU, Float
> should actually be a typealias for Float80 even on some 32-bit machines. In
> neither interpretation does it mean that Float should simply be a typealias
> for what's now called Double.
> IIRC, `Int` is typealiased to the target's biggest
> native/efficient/practical integer type, regardless of its bit-depth
> (although I believe some do exist, I can’t think of any CPUs in which those
> are different). I don’t see why it shouldn’t be the same way with floats…
> IMHO, `Float` should be typealiased to the biggest
> native/efficient/practical floating point type, which I think is pretty
> universally Float64. I’m under the impression that Intel’s 80-bit format is
> intended to be an interim representation which is automatically converted
> to/from 64-bit, and loading & storing a full 80-bits is a non-trivial
> matter. I’m not even sure if the standard “math.h" functions are defined
> for Float80 arguments. If Float80 is just as native/efficient/practical as
> Float64, I wouldn’t object to Float being typealiased to Float80 on such
> platforms.
>
> > Another issue to consider: a number like 42 is stored exactly regardless
> of whether you're using an Int32 or an Int64. However, a number like 1.1 is
> not stored exactly as a binary floating point type, and it's approximated
> *differently* as a Float than as a Double. Thus, it can be essential to
> consider what kind of floating point type you're using in scenarios even
> when the number is small, whereas the same is not true for integer types.
> Oh I know. I’m not arguing that floating point math isn’t messy, just that
> since we can use “Int” for when we don’t care and “IntXX” for when we do,
> we should also be able to use “Float” when we don’t care and “FloatXX” when
> we do. If someone’s worried about the exact value of “1.1”, they should be
> specifying the bit-depth anyway. Otherwise, give them most precise type
> which can work with the language’s goals.
>

I wouldn't be opposed to renaming Float and Double to Float32 and Float64,
but I would care if Float were typealiased to different types on different
platforms. That solution is a non-starter for me because something as
simple as (1.1 + 1.1) would evaluate to a different result depending on the
machine. That's a problem. An analogous issue does not come into play with
Int because 1 + 1 == 2 regardless of the size of Int. Swift traps when the
max value that can be stored in an Int is exceeded, so it is not possible
to obtain two different results on two different machines.

Have we (meaning the list in general, not you & me in particular) had this
> conversation before? This feels familiar...
>

It does, doesn't it? I've been reading this list for too long.


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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Brent Royal-Gordon via swift-evolution]

> One initial bit of feedback -  I believe if you have existential types, I 
> believe you can define Sequence Element directly, rather than with a type 
> alias. e.g.
> 
> protocol Sequence {
>   associatedtype Element
>   associatedtype Iterator: any IteratorProtocol.Element==Element> 
>   associatedtype SubSequence: any
>   …
> }

That's not really the same thing. Any is an existential, not 
a protocol. It's basically an automatically-generated version of our current 
`AnyIterator` type (though with some additional flexibility). It can't 
appear on the right side of a `:`, any more than AnyIterator could.

What *would* work is allowing `where` clauses on associated types:

> protocol Sequence {
>   associatedtype Element
>   associatedtype Iterator: IteratorProtocol where Iterator.Element==Element
>   associatedtype SubSequence: Sequence where SubSequence.Element == Element
>   …
> }

I believe this is part of the generics manifesto.

-- 
Brent Royal-Gordon
Architechies

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

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

[David Sweeris via swift-evolution]

On May 23, 2016, at 8:18 PM, Xiaodi Wu  wrote:
> 
> Int is the same size as Int64 on a 64-bit machine but the same size as Int32 
> on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that 
> handle 64-bit and even 80-bit floating point types. Therefore, it does not 
> make sense for Float to be Float32 on a 32-bit machine, as would be the case 
> in one interpretation of what it means to mirror naming "conventions." 
> However, if you interpret the convention to mean that Float should be the 
> largest floating point type supported by the FPU, Float should actually be a 
> typealias for Float80 even on some 32-bit machines. In neither interpretation 
> does it mean that Float should simply be a typealias for what's now called 
> Double.
IIRC, `Int` is typealiased to the target's biggest native/efficient/practical 
integer type, regardless of its bit-depth (although I believe some do exist, I 
can’t think of any CPUs in which those are different). I don’t see why it 
shouldn’t be the same way with floats… IMHO, `Float` should be typealiased to 
the biggest native/efficient/practical floating point type, which I think is 
pretty universally Float64. I’m under the impression that Intel’s 80-bit format 
is intended to be an interim representation which is automatically converted 
to/from 64-bit, and loading & storing a full 80-bits is a non-trivial matter. 
I’m not even sure if the standard “math.h" functions are defined for Float80 
arguments. If Float80 is just as native/efficient/practical as Float64, I 
wouldn’t object to Float being typealiased to Float80 on such platforms.

> Another issue to consider: a number like 42 is stored exactly regardless of 
> whether you're using an Int32 or an Int64. However, a number like 1.1 is not 
> stored exactly as a binary floating point type, and it's approximated 
> *differently* as a Float than as a Double. Thus, it can be essential to 
> consider what kind of floating point type you're using in scenarios even when 
> the number is small, whereas the same is not true for integer types.
Oh I know. I’m not arguing that floating point math isn’t messy, just that 
since we can use “Int” for when we don’t care and “IntXX” for when we do, we 
should also be able to use “Float” when we don’t care and “FloatXX” when we do. 
If someone’s worried about the exact value of “1.1”, they should be specifying 
the bit-depth anyway. Otherwise, give them most precise type which can work 
with the language’s goals.

Have we (meaning the list in general, not you & me in particular) had this 
conversation before? This feels familiar...

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

Re: [swift-evolution] Make access control private by default.

[John McCall via swift-evolution]

> On May 23, 2016, at 3:43 PM, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
> I was just about to mention this too. I think it's interesting that
> one can write a simple application in Swift without having to worry
> (much) about visibility of elements. Please note I'm talking about
> applications not frameworks.

I'm glad this is working for you, because this is exactly the intent.

> I also agree this is good for teachability because you can worry about
> more important aspects of programming (functionality and structure)
> than just the correct visibility (that makes no difference to a
> student until they move to coding a framework themselves).

Right.  I think the phrase Chris likes to pull out here is "progressive 
disclosure":
the language should allow you to focus on learning one lesson at a time.
Making students write "public" everywhere doesn't make understand good
code structure and encapsulation; it just forces them to learn a magic word.

In fact — and here I'll confess to not being up-to-date on CS pedagogy
research, and if I'm mistaken I would be happy to be corrected — intuitively I 
find
it improbable that you can really teach encapsulation to intro students at all.
I mean, sure, you can teach the terminology and mechanics, and you can
mandate a particular code style for their assignments, but they won't really
understand the value until they've experienced the problems of code that
*isn't* well-abstracted.

> But I also agree that, to some extent, private may not make sense if
> the default visibility is already not visible outside the current
> module but should that be an excuse to just drop it?

It makes sense for programmers to be able to develop strong abstractions
within a module.  We're not going to drop private.

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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I’ll fix that. I also forgot to change Impact on existing code section. I’ll do 
that when Austin had time to look at it.

This proposal will break protocol A: class {} if we get protocol A: Any 
{} as replacement.



-- 
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matt...@anandabits.com) schrieb:

Looks pretty good.  Just one minor correction.

Under not valid examples that may be supported in the future you have this:

extension A where Self == UIView  

Where you should have this:

extension A where Self : UIView  

Sent from my iPad

On May 21, 2016, at 7:42 AM, Adrian Zubarev via swift-evolution 
 wrote:

Proposal was updated as an enhancement proposal to SE–0095. You can read the 
new draft here:

https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md
@Austin: I used some peaces of your enhancement proposal and you’re co-author 
to this proposal now. If you want to polish something feel free to submit a PR.

What else do we need in this proposal?


-- 
Adrian Zubarev
Sent with Airmail
___
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`

[Dany St-Amant via swift-evolution]

> Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution 
>  a écrit :
> 
> I wrote some code tonight to experiment with this kind of thing. I apologize 
> if it's off-topic for the thread, but it might be useful to others who want 
> to experiment. 
> 
> 
> 
> //: Playground - noun: a place where people can play
> 
> import Cocoa
> 
> infix operator • { precedence 180 }
> infix operator → { associativity left precedence 70 }
> infix operator … { associativity right precedence 60 }
> 
> func → ( lhs: Bool, rhs: T ) -> T? {
>   return lhs ? rhs : nil
> }
> 
> func … ( lhs:T?, rhs:T ) -> T {
>   return lhs != nil ? lhs! : rhs
> }
> 
> func depends( dep:I, _ closure: (I)->(O) ) -> O {
>   return closure( dep )
> }
> 
> func • ( lhs: I, rhs: (I)->(O) ) -> O {
>   return depends( lhs, rhs )
> }
> 
> /* Example using "depends" */
> 
> let
>   str:String,
>   i = 7
> 
> str = depends( i ){
>   $0==2 → "two" …
>   $0==3 → "three" …
>   $0==4 → "four" …
>   "other"
> }
> 

Hmm… replacing -> by ?, and … by : you get:

str = depends( i ){
$0==2 ? "two" :
$0==3 ? "three" :
$0==4 ? "four" :
"other"
}

which work as is without a need to define new operators.

Dany

> /* Example using "•" operator as "depends" */
> 
> enum People { case Kurtz, Popescu, Lime, Martins }
> enum Order { case First, Second, Third, Unknown }
> 
> let
>   order:Order,
>   person:People = .Lime
> 
> order = person • {
>   $0 == .Kurtz → .First …
>   $0 == .Popescu → .Second …
>   $0 == .Lime → .Third …
>   .Unknown
> }
> 
> 
> I also have some trepidation about posting it here, because it might have 
> bugs. I wans't sure what "precedence" and "associativity" should be, for 
> example. But it does make it more convenient to test alternative characters 
> for operators, etc.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution 
> > wrote:
> 
> On 09.04.2016 9:31, Brent Royal-Gordon wrote:
> This design is still very much under development—it hasn't even been 
> reviewed, let alone added to the language. Here's the draft 
> proposal:  
> >
> 
> I'm not saying that this will necessarily be a solution that ends up being 
> accepted—I'm merely saying that yes, it's something people are thinking about 
> and designing; it's just been inactive for a few weeks.
> 
> Oh, I see. Thank you for letting know. Just missed "you would be able" in 
> your previous message, did read it as "you are able", so was trying to find 
> this in current Swift version. OK, glad to know that most likely we'll have 
> improvements in enums eterations for Swift 3.0.
> 
> ___
> 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] Proposal SE-0009 Reconsideration

[Rob Mayoff via swift-evolution]

On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution
 wrote:
> Dunno about other IDEs, but Xcode's syntax highlighting can change the size, 
> typeface (bold, italic, etc), and even the font. You can make instance 
> variables show up as 24pt comic sans, if you want. You can’t do polkadot, 
> though… apparently that’s going too far.

Unfortunately, doing this can trigger a longstanding Xcode bug that
makes it very difficult to edit any file that's substantially longer
than the height of your window.

http://stackoverflow.com/questions/26761295/xcode-6-code-editor-erratic-behaviour
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Int is the same size as Int64 on a 64-bit machine but the same size as
Int32 on a 32-bit machine. By contrast, modern 32-bit architectures have
FPUs that handle 64-bit and even 80-bit floating point types. Therefore, it
does not make sense for Float to be Float32 on a 32-bit machine, as would
be the case in one interpretation of what it means to mirror naming
"conventions." However, if you interpret the convention to mean that Float
should be the largest floating point type supported by the FPU, Float
should actually be a typealias for Float80 even on some 32-bit machines. In
neither interpretation does it mean that Float should simply be a typealias
for what's now called Double.

Another issue to consider: a number like 42 is stored exactly regardless of
whether you're using an Int32 or an Int64. However, a number like 1.1 is
not stored exactly as a binary floating point type, and it's approximated
*differently* as a Float than as a Double. Thus, it can be essential to
consider what kind of floating point type you're using in scenarios even
when the number is small, whereas the same is not true for integer types.


On Mon, May 23, 2016 at 7:48 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> I'd prefer they mirror the integer type naming "conventions", that is have
> an explicit "Float32" and "Float64" type, with "Float" being a typealias
> for Float64.
>
> Sent from my iPhone
>
> On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi everyone,
>
> Is there any draft/proposal related to this suggestion?
>
> Best,
>
> — A
>
> On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> I'm curious how other members of the Swift community feel about the
> clarity of the "Double" and "Float" type names. It seems incongruous that
> the default type for integers is "Int", but the default type for floating
> point numbers is not "Float".
>
> What if the name "Float" were given to the intrinsic, 64-bit floating
> point type? (And the existing "Float" and "Double" names were removed in
> favor of "Float32" and "Float64"?)
>
>
> *Discussion:*
>
> I understand the origins of these names in single- and double-precision
> IEEE floats. But this distinction feels like a holdover from C (and a
> 32-bit world), rather than a natural fit for Swift.
>
> Here are some reasons to *keep Double and Float as they are* (numbered
> for easy reference, but otherwise unordered):
>
>1. "Double" and "Float" are more natural for developers who are
>"familiar with C-like languages."
>2. A corollary: A 64-bit "Float" type could be confusing to those
>developers.
>3. Another corollary: Swift needs to interoperate with Objective C,
>and its "float" and "double" types.
>4. Renaming these types would open the door to bike-shedding every
>type name and keyword in the language.
>5. Changing the meaning of an existing type ("Float") would be a bit
>PITA for existing code (although an automated migration from "Float" to
>"Float32" and "Double" to "Float" should be possible).
>6. Renaming a fundamental type would take considerable effort.
>
> Here are some reasons to *rename these types*:
>
>1. The default for a "float literal" in Swift is a 64-bit value. It
>would feel natural if that that value were of type "Float".
>2. There are size-specific names for 32-bit ("Float32") and 64-bit
>("Float64") floating point types. For cases where a size-specific type is
>needed, a size-specific name like "Float32" probably makes the intention of
>the code more clear (compared to just "Float").
>3. Apple's Objective C APIs generally use aliased types like "CGFloat"
>rather than raw float or double types.
>4. There is precedent for "Float" types being 64-bit in other
>languages like Ruby, Python and Go (as long as the hardware supports it).
>5. What kind of a name for a type is "Double" anyways, amirite?
>
> (that last one is a joke, BTW)
>
> What do you think? Do you agree or disagree with any of my assessments?
> Are there any pros or cons that I've missed? Is the level of effort so
> large that it makes this change impractical? Is it a colossal waste of
> human effort to even consider a change like this?
>
> Thanks for your time and attention,
> Alex Johnson (@nonsensery)
> ___
> 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] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality

[Dany St-Amant via swift-evolution]

Why reinvent the wheel, when the old trusty (but a bit cryptic according to 
some) tri-op can do the trick…

> Le 23 mai 2016 à 04:29, Charles Constant via swift-evolution 
>  a écrit :
> 
> Here's a few examples of what this change would allow. 
> 
> I just plucked the first instances of other people's switch statements that I 
> found on GitHub. 
> 
> If there were an easy way to search GitHub for chained ternary expressions, I 
> would have added some examples of those too, since they could all be improved 
> with this where clause + ??. 
> 
> 
>   mutating func toggle() {
>   switch self{
>   case Off:
>   self = On
>   case On:
>   self = Off  
>   }   
>   }
> 
> 
> 
>   mutating func toggle() {
>   self = .On where (self == .Off) ?? .Off
>   }
> 

mutating func toggle() { self = self == .Off ? .On : .Off }

> 
>   switch switchNumberThree {
>   case 10, 11, 12:
>   println("It is \(switchNumberThree)")
>   default:
>   ("It is none of them!")
>   }
> 
> 
>   println(
>   "It is \(switchNumberThree)" where 10...12 ~= switchNumberThree
>   ?? "It is none of them!"
>   )
> 

print( 10...12 ~= switchNumberThree ? "It is \(switchNumberThree)"
   : "It's none of them" )

> 
>   switch x {
>   case 1:
>   j++
>   case 2:
>   j++
>   case 3:
>   j++
>   case 4:
>   j++
>   fallthrough
>   case 5:
>   j++
>   fallthrough
>   default:
>   j++
>   }
> 
> 
>   j = j+1 where (4...5 ~= x) ?? j+2
> 

Broken conversion:
j += 4...5 ~= x ? 1 : 2

Proper conversion:
j += 4 ~= x ? 3 : 5 ~= x ? 2 : 1

Earlier e-mail example:
> let foo = 
> "positive" where ( bar > 0 )  ?? 
> "negative" where ( bar < 0 ) ?? 
> "zero"

let foo = bar > 0 ? "positive" :
  bar < 0 ? "negative" :
  "zero"

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

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

[David Sweeris via swift-evolution]

I'd prefer they mirror the integer type naming "conventions", that is have an 
explicit "Float32" and "Float64" type, with "Float" being a typealias for 
Float64.

Sent from my iPhone

> On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Is there any draft/proposal related to this suggestion?
> 
> Best,
> 
> — A
> 
>> On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> I'm curious how other members of the Swift community feel about the clarity 
>> of the "Double" and "Float" type names. It seems incongruous that the 
>> default type for integers is "Int", but the default type for floating point 
>> numbers is not "Float".
>> 
>> What if the name "Float" were given to the intrinsic, 64-bit floating point 
>> type? (And the existing "Float" and "Double" names were removed in favor of 
>> "Float32" and "Float64"?)
>> 
>> 
>> Discussion:
>> 
>> I understand the origins of these names in single- and double-precision IEEE 
>> floats. But this distinction feels like a holdover from C (and a 32-bit 
>> world), rather than a natural fit for Swift.
>> 
>> Here are some reasons to keep Double and Float as they are (numbered for 
>> easy reference, but otherwise unordered):
>> "Double" and "Float" are more natural for developers who are "familiar with 
>> C-like languages."
>> A corollary: A 64-bit "Float" type could be confusing to those developers.
>> Another corollary: Swift needs to interoperate with Objective C, and its 
>> "float" and "double" types.
>> Renaming these types would open the door to bike-shedding every type name 
>> and keyword in the language.
>> Changing the meaning of an existing type ("Float") would be a bit PITA for 
>> existing code (although an automated migration from "Float" to "Float32" and 
>> "Double" to "Float" should be possible).
>> Renaming a fundamental type would take considerable effort.
>> Here are some reasons to rename these types:
>> The default for a "float literal" in Swift is a 64-bit value. It would feel 
>> natural if that that value were of type "Float".
>> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
>> floating point types. For cases where a size-specific type is needed, a 
>> size-specific name like "Float32" probably makes the intention of the code 
>> more clear (compared to just "Float").
>> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
>> than raw float or double types.
>> There is precedent for "Float" types being 64-bit in other languages like 
>> Ruby, Python and Go (as long as the hardware supports it).
>> What kind of a name for a type is "Double" anyways, amirite?
>> (that last one is a joke, BTW)
>> 
>> What do you think? Do you agree or disagree with any of my assessments? Are 
>> there any pros or cons that I've missed? Is the level of effort so large 
>> that it makes this change impractical? Is it a colossal waste of human 
>> effort to even consider a change like this?
>> 
>> Thanks for your time and attention,
>> Alex Johnson (@nonsensery)
>>  ___
>> 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-0083: Remove bridging conversion behavior from dynamic casts

[Jordan Rose via swift-evolution]

I am way late, but I share Brent’s concerns. I don’t think this addresses the 
very common case of “getting a String out of a heterogeneous dictionary”.

let name = plist[“name”] as! String

becomes one of these:

let name = plist[“name”] as! NSString as String
let name = String(plist[“name”] as! NSString)
let name = String(forceBridging: plist[“name”]) // not in the proposal

none of which I’m particularly happy with. 

Jordan


> On May 19, 2016, at 02:31, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>>  * What is your evaluation of the proposal?
> 
> The review is technically over, but I don't believe a decision has been 
> announced yet, so...
> 
> I am generally in favor, but I have a serious concern about the readability 
> of certain conversions with this change. To wit, conversions like these:
> 
>   myArray as! [NSView]
>   myDictionary as! [String: NSView]
> 
> Are about to become something more like these:
> 
>   [NSView](forcedLazyBridging: myArray)
>   [String: NSView](forcedLazyBridging: myDictionary)
>   
> Or these:
> 
>   Array(forcedLazyBridging: myArray)
>   Dictionary(forcedLazyBridging: myDictionary)
> 
> Either option is a significant regression in code readability compared to the 
> status quo.
> 
> It's enough to make me wonder if we shouldn't have special-cased conversion 
> methods for NSArray, NSDictionary, and NSSet:
> 
>   myArray.of(NSView)  // returns [NSView]
>   myDictionary.of(NSView, for: String)// returns [String: NSView]
>   mySet.of(NSView)// returns 
> Set
> 
> On the other hand, if you *don't* have to specify an element type, these 
> aren't so bad:
> 
>   Array(forcedLazyBridging: myArray)
>   Dictionary(forcedLazyBridging: myDictionary)
> 
> And it gets even better if you use something a little saner than 
> `forcedLazyBridging` for the label.
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes. Conversions are a mess, and it'll be nice to clean them up.
> 
>>  * 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?
> 
> Most languages I've used have had much simpler cast systems with nothing 
> particularly close to Swift's bridging casts.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Quick reading.
> 
> -- 
> 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] [Review] SE-0093: Adding a public base property to slices

[Max Moiseev via swift-evolution]

That is correct, the proposed change only applies to the concrete slice types 
that are provided by the standard library.

Max


> On May 23, 2016, at 5:13 PM, Jordan Rose  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md
>  
> ]
> 
> Hey, Max. For clarification, this isn’t adding anything to the requirements 
> for slice types, correct? That is, the result type of 'subscript(_: Range)' 
> has no additional requirements? (Why I ask: there would be plenty of 
> implementations of slices that may not otherwise need a reference to the 
> original collection.)
> 
> I’m vaguely uncomfortable with this because I feel like it’s violating some 
> abstraction or allowing unsafe indexing, but of course that’s no more unsafe 
> than with any other collection.
> 
> Jordan
> 
> 
>> On May 19, 2016, at 16:43, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0093: Adding a public base property to slices"
>> begins now and runs through May 23. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.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 contribute to 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,
>> 
>> Dave Abrahams
>> 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

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md
 
]

Hey, Max. For clarification, this isn’t adding anything to the requirements for 
slice types, correct? That is, the result type of 'subscript(_: Range)' has no 
additional requirements? (Why I ask: there would be plenty of implementations 
of slices that may not otherwise need a reference to the original collection.)

I’m vaguely uncomfortable with this because I feel like it’s violating some 
abstraction or allowing unsafe indexing, but of course that’s no more unsafe 
than with any other collection.

Jordan


> On May 19, 2016, at 16:43, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> Hello Swift community,
> 
> The review of "SE-0093: Adding a public base property to slices"
> begins now and runs through May 23. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.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 contribute to 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,
> 
> Dave Abrahams
> 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

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

[Adriano Ferreira via swift-evolution]

Hi everyone,

Is there any draft/proposal related to this suggestion?

Best,

— A

> On Jan 4, 2016, at 3:58 PM, Alex Johnson via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> I'm curious how other members of the Swift community feel about the clarity 
> of the "Double" and "Float" type names. It seems incongruous that the default 
> type for integers is "Int", but the default type for floating point numbers 
> is not "Float".
> 
> What if the name "Float" were given to the intrinsic, 64-bit floating point 
> type? (And the existing "Float" and "Double" names were removed in favor of 
> "Float32" and "Float64"?)
> 
> 
> Discussion:
> 
> I understand the origins of these names in single- and double-precision IEEE 
> floats. But this distinction feels like a holdover from C (and a 32-bit 
> world), rather than a natural fit for Swift.
> 
> Here are some reasons to keep Double and Float as they are (numbered for easy 
> reference, but otherwise unordered):
> "Double" and "Float" are more natural for developers who are "familiar with 
> C-like languages."
> A corollary: A 64-bit "Float" type could be confusing to those developers.
> Another corollary: Swift needs to interoperate with Objective C, and its 
> "float" and "double" types.
> Renaming these types would open the door to bike-shedding every type name and 
> keyword in the language.
> Changing the meaning of an existing type ("Float") would be a bit PITA for 
> existing code (although an automated migration from "Float" to "Float32" and 
> "Double" to "Float" should be possible).
> Renaming a fundamental type would take considerable effort.
> Here are some reasons to rename these types:
> The default for a "float literal" in Swift is a 64-bit value. It would feel 
> natural if that that value were of type "Float".
> There are size-specific names for 32-bit ("Float32") and 64-bit ("Float64") 
> floating point types. For cases where a size-specific type is needed, a 
> size-specific name like "Float32" probably makes the intention of the code 
> more clear (compared to just "Float").
> Apple's Objective C APIs generally use aliased types like "CGFloat" rather 
> than raw float or double types.
> There is precedent for "Float" types being 64-bit in other languages like 
> Ruby, Python and Go (as long as the hardware supports it).
> What kind of a name for a type is "Double" anyways, amirite?
> (that last one is a joke, BTW)
> 
> What do you think? Do you agree or disagree with any of my assessments? Are 
> there any pros or cons that I've missed? Is the level of effort so large that 
> it makes this change impractical? Is it a colossal waste of human effort to 
> even consider a change like this?
> 
> Thanks for your time and attention,
> Alex Johnson (@nonsensery)
>  ___
> 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] Proposal: Deprecate optionals in string interpolation

[Chris Lattner via swift-evolution]

> On May 23, 2016, at 12:12 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> If the URL path property was defined not to return ‘String?' but to return 
>> ‘Any’ (which can of course hold an Optional just like it can hold any other 
>> type) what would the proposed compiler behavior be?
> 
> No warning. Since you cast Optional to Any, no warning can even be issued 
> since that will eventually be determined during runtime, there's not much the 
> compiler can do here.

I agree.  It is important for optionals to be string literal convertible in 
generic situations as well as when boxed in an existential like Any.  That 
said, emitting a warning when the compiler knows statically that it has an 
optional makes a lot of sense.

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

Re: [swift-evolution] Winding down the Swift 3 release

[Chris Lattner via swift-evolution]

On May 23, 2016, at 2:17 AM, Jeremy Pereira via swift-evolution 
 wrote:
> The collection model, API guidelines and standard library are actually 
> irrelevant to the ABI. The standard library API and the Swift ABI are 
> distinct orthogonal concepts.

I’m not sure what you’re saying.  If you change the API shipped by the standard 
library, it obviously breaks anything that links to it.

The whole point of ABI stability is to not break apps built with old versions 
of Swift compiler / standard library.

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

[swift-evolution] [Amendment] SE-0022: Referencing the Objective-C selector of a method

[Joe Groff via swift-evolution]

Hi everyone. Accepted proposal SE-0022, "Referencing the Objective-C selector 
of a method", has been amended with the following changes:


https://github.com/apple/swift-evolution/commit/1dfd6cd4fc2e9874d5db8aef6a5f41d6556b2ca2

Alex Hoppen, who undertook the work to implement the related proposal SE-0064, 
"Referencing the Objective-C selector of property getters and setters", noted 
that by accepting arbitrary expressions inside a #selector expression, we made 
it difficult to handle the getter and setter selector cases introduced by 
SE-0064. It was not the original proposal's attempt to accept arbitrary 
expressions, only expressions that happened to form a valid method reference, 
and the amendment seeks to clarify this intent.

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

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

[Kevin Ballard via swift-evolution]

On Mon, May 23, 2016, at 03:15 PM, Max Moiseev wrote:
> Hi Kevin,
> 
> Thanks for reviewing this proposal.
> 
> It is my poor choice of words to be blamed for the confusion. There is 
> definitely no reason for the new property to only be available for the 
> MutableRandomAccessSlice type. Moreover, since all the slice types are 
> generated with GYB now, it would be more code ;-)
> 
> The intention is to add the new property to ALL the slice types.

Ah hah, you're right, I missed the following line when reading:

> The same change is applicable to both mutable and immutable slice types.

So +1, though I'm still in favor of renaming `_base` to `base` and then adding 
a computed `_base` property back if the stdlib breakage is too high.

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

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

[Max Moiseev via swift-evolution]

Hi Kevin,

Thanks for reviewing this proposal.

It is my poor choice of words to be blamed for the confusion. There is 
definitely no reason for the new property to only be available for the 
MutableRandomAccessSlice type. Moreover, since all the slice types are 
generated with GYB now, it would be more code ;-)

The intention is to add the new property to ALL the slice types.

Regards,
Max


> On May 23, 2016, at 3:08 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> On Thu, May 19, 2016, at 04:43 PM, Dave Abrahams via swift-evolution wrote:
>>  * What is your evaluation of the proposal?
> 
> The motivation sounds reasonable, as does the solution. But it seems odd to 
> expose a property `base` on MutableRandomAccessSlice without exposing it on 
> any other slice type. I'd much rather expose it everywhere, ideally by 
> renaming the `_base` property as suggested in the alternatives section. 
> Stdlib breakage can be handled on a temporary basis by providing the `_base` 
> accessor as a computed property that returns `base`, though of course the 
> goal should be to remove this entirely (or hopefully not have it at all if 
> there's not too much stdlib breakage). And such a change should still be 
> purely additive from the perspective of third-party code.
> 
>>  * Is the problem being addressed significant enough to warrant a
>>  change to Swift?
> 
> Yes. This is a relatively minor change but it allows for better performance.
> 
>>  * 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?
> 
> I can't think of any languages with this offhand.
> 
>>  * How much effort did you put into your review? A glance, a
>>  quick reading, or an in-depth study?
> 
> A quick reading.
> 
> -Kevin Ballard
> ___
> 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-0093: Adding a public base property to slices

[Kevin Ballard via swift-evolution]

On Thu, May 19, 2016, at 04:43 PM, Dave Abrahams via swift-evolution wrote:
>   * What is your evaluation of the proposal?

The motivation sounds reasonable, as does the solution. But it seems odd to 
expose a property `base` on MutableRandomAccessSlice without exposing it on any 
other slice type. I'd much rather expose it everywhere, ideally by renaming the 
`_base` property as suggested in the alternatives section. Stdlib breakage can 
be handled on a temporary basis by providing the `_base` accessor as a computed 
property that returns `base`, though of course the goal should be to remove 
this entirely (or hopefully not have it at all if there's not too much stdlib 
breakage). And such a change should still be purely additive from the 
perspective of third-party code.

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

Yes. This is a relatively minor change but it allows for better performance.

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

I can't think of any languages with this offhand.

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

A quick reading.

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

Re: [swift-evolution] Proposal SE-0009 Reconsideration

[Vladimir.S via swift-evolution]

On 23.05.2016 21:41, Charles Srstka via swift-evolution wrote:

Plus, I might end up having to use a different source editor sometimes,
particularly when I’m doing a large refactor and Xcode is stuck in its
“SourceKitService crash every time two characters are typed” thing. I’d
really rather have things differentiable in the language itself rather than
relying on external crutches.



IMO it's weird to rely on XCode features when we discuss some features of 
the language. Not always Swift code is edited in XCode, not always in IDE 
that supports different colors for different kind of variables, not always 
you have IDE at all and you can have just editor with simple(it will not 
parse/compile Swift code/project) coloring for base language constructions.


As for this proposal. I don't believe(based on community and core team 
response) the situation with implicit 'self.' could be changed. So let's 
use lints and other tools to achieve the target of warning for implicit 
'self.'. I suggest to move forward the idea of warning(and 'fix') for 
shadowing of variables in general and property and local variable in 
particular.

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

Re: [swift-evolution] Make access control private by default.

[Jean-Daniel Dupas via swift-evolution]

> Le 23 mai 2016 à 23:21, Knut Lorenzen via swift-evolution 
>  a écrit :
> 
> 
>> On 19 May 2016, at 19:18, John McCall  wrote:
>> 
>> That is not at all true.  The dynamic OOP languages do not, as a rule, have 
>> any access control at all.  Java and C# default to package access, which is 
>> analogous to internal.  C++ is, as always, complicated and different.
> 
> Class members are private by default in both Java and C#. As are ivars and 
> selectors in Objective-C (the latter having to be redeclared in the header 
> file for module-wide access). Swift definitely gives greater default scope to 
> class members in comparison to other OOP languages.

On Java, they are package-private, not private by default, which is closer to 
module visibility of swift than private.


> 
> Knut
> ___
> 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Sean Heber via swift-evolution]

Bikeshedding: Is it grammatically possible (or even desirable) to skip the 
“any” token and just have something like this:

var view: 
init(view: ) {}
if let mergedValue = button as?  {}
let a: >>

I’m not even sure there’s a huge advantage to leaving it out (avoid capturing a 
new keyword?) - just thought I’d ask!

And while I’m here asking about (likely very silly) things, I wanted to note 
that the < and > symbols are heavily ingrained as generics to me and this seems 
like.. not really the same kind of thing? Has the potential for confusion about 
this been considered at all? It’s almost like what is being expressed is, 
“here’s a set/collection of requirements” and, in that case, it almost seems 
like it should look more like an array:

var view: [UIView, SomeProtocol]
init(view: [UIView, SomeProtocol]) {}
if let mergedValue = button as? [UIView, SomeProtocol] {}
let a: [UIScrollView, [UITableView, [UIView, ProtocolA]]]

Would that lead to a better syntax if such things as generic protocols were 
possible (assuming they are even desirable)? Example:

let a: [UIView, MyProtocol]

l8r
Sean - who might just be confused about things due to a lack of attention 
spa... ooh shiny things!


> On May 23, 2016, at 3:15 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Fixed a few things: 
> https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md
> 
> Tell me if I left out any topic or detail.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 23. Mai 2016 bei 12:08:45, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> I’ll fix that. I also forgot to change Impact on existing code section. I’ll 
>> do that when Austin had time to look at it.
>> 
>> This proposal will break protocol A: class {} if we get protocol A: 
>> Any {} as replacement.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matt...@anandabits.com) 
>> schrieb:
>> 
>>> Looks pretty good.  Just one minor correction.
>>> 
>>> Under not valid examples that may be supported in the future you have this:
>>> 
>>> extension A where Self == UIView 
>>> 
>>> 
>>> Where you should have this:
>>> 
>>> extension A where Self : UIView 
>>> 
>>> Sent from my iPad
>>> 
>>> On May 21, 2016, at 7:42 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
 Proposal was updated as an enhancement proposal to SE–0095. You can read 
 the new draft here:
 
• 
 https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md
 @Austin: I used some peaces of your enhancement proposal and you’re 
 co-author to this proposal now. If you want to polish something feel free 
 to submit a PR.
 
• What else do we need in this proposal?
 
 
 -- 
 Adrian Zubarev
 Sent with Airmail
 ___
 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] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

Fixed a few things: 
https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md

Tell me if I left out any topic or detail.



-- 
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 12:08:45, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

I’ll fix that. I also forgot to change Impact on existing code section. I’ll do 
that when Austin had time to look at it.

This proposal will break protocol A: class {} if we get protocol A: Any 
{} as replacement.



-- 
Adrian Zubarev
Sent with Airmail

Am 23. Mai 2016 bei 02:52:31, Matthew Johnson (matt...@anandabits.com) schrieb:

Looks pretty good.  Just one minor correction.

Under not valid examples that may be supported in the future you have this:

extension A where Self == UIView  


Where you should have this:

extension A where Self : UIView  

Sent from my iPad

On May 21, 2016, at 7:42 AM, Adrian Zubarev via swift-evolution 
 wrote:

Proposal was updated as an enhancement proposal to SE–0095. You can read the 
new draft here:

https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md
@Austin: I used some peaces of your enhancement proposal and you’re co-author 
to this proposal now. If you want to polish something feel free to submit a PR.

What else do we need in this proposal?


-- 
Adrian Zubarev
Sent with Airmail
___
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] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 23, 2016, at 1:21 PM, Thorsten Seitz  wrote:
> 
> 
>>> Am 23.05.2016 um 19:17 schrieb Matthew Johnson :
>>> 
>>> 
>>> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution 
 :
 
 I agree; the difference between protocols with and without associated 
 types has been an endless source of confusion for a lot of people.
 
 Speaking of which, for those who care I rewrote the draft proposal to 
 attempt a much more rigorous treatment of the semantics of the generalized 
 existential, including a discussion about existential type equivalence and 
 subtyping. It would be nice to see people poke holes in my logic so I can 
 patch them up. 
 https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>>> 
>>> I think that *all* methods should be available - at least in principle - 
>>> with associated types 
>>> - replaced by their upper bounds (i.e. Any if no constraints have been 
>>> given either by the protocol definition itself or th existential) if in 
>>> covariant position and 
>>> - replaced by their lower bounds if in contravariant position
>>> 
>>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>>> always the bottom type (called `Nothing` in Swift and not be confused with 
>>> optionals). The bottom type has no members and therefore a method 
>>> referencing that type cannot be called and is effectively not available.
>> 
>> Called `Nothing` in Swift?  Where do you get that?  `func foo(s: Nothing) 
>> {}` gives me “use of undeclared type `Nothing`”.  If Swift had a bottom type 
>> wouldn’t we be able to declare a function accepting an argument of type 
>> `Nothing` (we could just never call it because we couldn’t construct an 
>> argument).
> 
> oops, sorry, I had wanted to type „called `Nothing` in Scala“ :-)

Lol that makes more sense. :)

> 
> -Thorsten
> 
> 
>> 
>>> 
>>> -Thorsten 
>>> 
 
 Austin
 
>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
>>  wrote:
>> 
>> 
>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> I agree with this. If we're certain we should reskin protocol<> as 
>> Any<>, we should frontload that change—in addition to affecting source 
>> code, it'd also influence the runtime behavior of type printing/parsing, 
>> which can't be statically migrated in the future. I think any discussion 
>> of extending existentials has to be considered out of scope for Swift 3, 
>> though, so the Any rename deserves its own proposal.
>> 
>> -Joe
> 
> 
> Its really unfortunate that the generics work is probably going to be 
> deferred. When you really dive in to protocol-oriented programming and 
> designing frameworks to be native Swift (taking advantage of Swift 
> features) the existential problem comes up a lot and leads to sub-optimal 
> designs, abandonment of type safety, or gobs of boilerplate.  
> 
> 
> Russ
> 
> ___
> 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] [Review] SE-0077: Improved operator declarations

[Антон Жилин via swift-evolution]

@CoreTeam Please, don't forget to merge pull request with fixes and
alternatives from review period.

@AnyoneElse Today is (formally) the last day of review. It may be your last
chance!

Apple repo link:
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md

My repo with some latest changes:
https://github.com/Anton3/swift-evolution/blob/master/proposals/0077-operator-precedence.md

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

Re: [swift-evolution] Static Dispatch Pitfalls

[Xiaodi Wu via swift-evolution]

On Mon, May 23, 2016 at 12:13 PM, Matthew Johnson 
wrote:

>
> On May 23, 2016, at 10:50 AM, Xiaodi Wu  wrote:
>
> On Mon, May 23, 2016 at 6:58 AM, Matthew Johnson 
> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On May 22, 2016, at 11:55 PM, Xiaodi Wu  wrote:
>>
>> On Sun, May 22, 2016 at 11:20 PM, Matthew Johnson > > wrote:
>>
>>>
>>> On May 22, 2016, at 4:22 PM, Xiaodi Wu  wrote:
>>>
>>> On Sun, May 22, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution
>>>  wrote:
>>>
 > The proposal is well thought out and makes a valiant attempt at
 handling all of the issues necessary.  But I don't support it for a number
 of reasons.  I think it highlights how awkward it would be to try to
 address shadowing on a case-by-case basis, which isn't necessarily obvious
 until you explore what a solution might look like.

 It does, but I'm just not sure what else you can do about it. If
 there's a warning, you need a way to silence it. If you ignore some cases
 (like creating a conflict by importing two modules), you'll miss some of
 the subtlest and hardest-to-fix bugs.

 Honestly, I'm tempted to say "you just can't ever shadow a final
 protocol method" and be done with it. If that prevents certain conformances
 or stops certain imports, so be it. You can always work around that with
 wrapper types or other techniques.

>>>
>>> You know, I think this might be cleverest solution. It adds a small
>>> limit to the language, but it doesn't unduly penalize retroactive modeling.
>>> If you control either the protocol or the conforming type, you can change
>>> the name of one of the methods so it doesn't shadow/get shadowed by the
>>> other.
>>>
>>>
>>> If you control the conforming type this isn’t too big an issue as long
>>> as the protocol was well designed.  However, if the protocol was poorly
>>> designed it could be an issue.  Maybe a method that can be more efficiently
>>> implemented by some types was not made a requirement, but an extension
>>> method (with a slower implementation) takes the obvious name.  Maybe you
>>> would be willing to live with the slower implementation when your type is
>>> accessed via the protocol, because at least it can still be used via the
>>> protocol, but you don’t want to burden callers who use the concrete type
>>> with the slow implementation.  What do you do then?
>>>
>>
>> If a method that really ought to be a protocol requirement isn't a
>> requirement and you don't control the protocol, well you're pretty much out
>> of luck even today. Any conforming type accessed via the protocol will use
>> the less efficient extension method and nothing about Brent's proposal
>> would make that worse or better.
>>
>> Shadowing of the slow extension method doesn't remove the burden. It may
>> make calling your fast implementation look nicer, but a less informed user
>> of your type would unwittingly call the slower implementation if they
>> access your type via the protocol. You could instead:
>> * come up with another name for your fast implementation; maybe the
>> "obvious" name for the method is "frobnicate"--then name your method
>> "quicklyFrobnicate";
>>
>> * or, decide you don't want to conform your type to a poorly designed
>> protocol after all, instead retroactively modeling your type and other
>> types of interest with a better designed protocol of your making.
>>
>>
>> Maybe you want the type to inter operate with code you don't control and
>> in order to do that it must conform to the protocol.  And you don't want to
>> obfuscate the interface to the concrete type because the protocol is poorly
>> designed.
>>
>
> I'm not sure this is a reasonable set of demands. I understand a protocol
> to be a contract.  If you decide to conform to a poorly designed protocol,
> you *should* have a poorly designed concrete type.
>
>
> This is crazy.  If a protocol happens to place a method in an extension
> rather than making it a default implementation of a requirement and I want
> to conform to it does not mean my concrete type should have be poorly
> designed.
>

Quite simply, I think it should.


>  Sure, when the 3rd party type uses my concrete type via the interface of
> its protocol it will not receive the benefits of a higher performance
> implementation.  But maybe interoperability is more important than the
> highest performance possible.
>

As you have said, the workaround is to provide two classes, one wrapping
the other. One provides interoperability, the other high performance.


>
> That is the purpose of a protocol, to provide certain guarantees, be they
> wise or unwise. To me, it's a bug rather than a feature to support papering
> over poor protocol design when conforming to a protocol, which also forces
> the poor design to be exposed only when 

Re: [swift-evolution] [Pitch] 'Double modulo' operator

[Tony Allevato via swift-evolution]

I've had to write a "true mod" function enough times across different
projects (usually for circular buffer indexing or angular arithmetic) that
it would absolutely support its inclusion in stdlib (for both integer and
floating point types).

The `%` operator historically has been implemented as "remainder" though
(even when called "modulus"), so while it would be nice to be "pure" and
have `%` do the right thing, I think it would be too confusing for users to
have the operator have a subtly different meaning compared to every other
programming language that looks like it.

I'm not crazy about the `%%` spelling, but I can't think of anything better
either at the moment.

On Mon, May 23, 2016 at 12:24 PM Adam Nemecek via swift-evolution <
swift-evolution@swift.org> wrote:

> That kind of breaks backwards compatibility.
>
> Also currently in swift, the % operator is called the remainder operator,
> not the modulo operator, so technically the current implementation is
> correct. In Haskell for example, there are two functions, rem (as in
> remainder) and mod (as in modulo). I guess we could leave % to mean
> remainder and introduce a mod function?
>
>
>
> On Mon, May 23, 2016 at 11:59 AM, Pyry Jahkola 
> wrote:
>
>> I wouldn't mind if the standard `%` operator worked like this and there
>> would be another top-level function `mod(p, q)` that worked like `%` in C.
>> The only times that I've ever needed the modulo operation (
>> https://en.wikipedia.org/wiki/Modulo_operation) to behave *some way* on
>> negative values it's always been the suggested
>> remainder-of-flooring-division way.
>>
>> On the other hand, there's a performance penalty (avoidable by using the
>> other mod operation), so I can understand if not everyone agrees.
>>
>> And like Steve said below, then we'll need a flooring division function
>> (or operator) as well. And a flooring `(f, r) = divmod(p, q)` too, I
>> suppose.
>>
>> In any case, I'm probably +1 if a well-thought proposal is brought to the
>> table.
>>
>> — Pyry
>>
>> Adam Nemecek wrote:
>>
>> Would you want to make this a function? Or an operator but a different
>> one?
>>
>> On Mon, May 23, 2016 at 7:30 AM, Stephen Canon  wrote:
>>
>>> I’m not really sold on the `%%` spelling, but I think the operation
>>> itself is worth exposing.  This is the remainder of a “flooring” division
>>> (as opposed to the C-family “truncating” division[1]).  If we do provide
>>> it, we should also provide the accompanying divide operation.
>>>
>>> – Steve
>>>
>>> [1] there are several other ways to define division beyond these two:
>>> remainder is always positive, remainder is closest to zero, etc.
>>> Truncating and flooring division are the most common by a wide margin,
>>> however.
>>>
>>
> ___
> 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] [Pitch] 'Double modulo' operator

[Adam Nemecek via swift-evolution]

That kind of breaks backwards compatibility.

Also currently in swift, the % operator is called the remainder operator,
not the modulo operator, so technically the current implementation is
correct. In Haskell for example, there are two functions, rem (as in
remainder) and mod (as in modulo). I guess we could leave % to mean
remainder and introduce a mod function?



On Mon, May 23, 2016 at 11:59 AM, Pyry Jahkola  wrote:

> I wouldn't mind if the standard `%` operator worked like this and there
> would be another top-level function `mod(p, q)` that worked like `%` in C.
> The only times that I've ever needed the modulo operation (
> https://en.wikipedia.org/wiki/Modulo_operation) to behave *some way* on
> negative values it's always been the suggested
> remainder-of-flooring-division way.
>
> On the other hand, there's a performance penalty (avoidable by using the
> other mod operation), so I can understand if not everyone agrees.
>
> And like Steve said below, then we'll need a flooring division function
> (or operator) as well. And a flooring `(f, r) = divmod(p, q)` too, I
> suppose.
>
> In any case, I'm probably +1 if a well-thought proposal is brought to the
> table.
>
> — Pyry
>
> Adam Nemecek wrote:
>
> Would you want to make this a function? Or an operator but a different one?
>
> On Mon, May 23, 2016 at 7:30 AM, Stephen Canon  wrote:
>
>> I’m not really sold on the `%%` spelling, but I think the operation
>> itself is worth exposing.  This is the remainder of a “flooring” division
>> (as opposed to the C-family “truncating” division[1]).  If we do provide
>> it, we should also provide the accompanying divide operation.
>>
>> – Steve
>>
>> [1] there are several other ways to define division beyond these two:
>> remainder is always positive, remainder is closest to zero, etc.
>> Truncating and flooring division are the most common by a wide margin,
>> however.
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

[Dany St-Amant via swift-evolution]

> Le 22 mai 2016 à 03:07, Adam Nemecek via swift-evolution 
>  a écrit :
> 
> Howdy,
> I think that the SignedNumberType should implement a method called sign that 
> will return -1 for negative numbers, 0 for 0 and 1 for positive numbers. This 
> is similar to the signum method in e.g. Java and similarly called methods in 
> other languages.
> 
> The implementation is fairly straight forward
> 
> extension SignedNumberType {
>   var sign: Self {
> if self == 0 {
>   return 0
> }
> else if self > 0 {
>   return 1
> }
> return -1
>   }
> } 
> 
> I was trying to implement is without branching by doing (x > 0) - (x < 0) but 
> I couldn't get the types right so I'm open to suggestions.
> 

Challenge accepted… Removed the if/else if, at the cost of double function call 
to a tri-op:

extension Bool {
func as01() -> T { return self ? 1 : 0 }
}

extension SignedNumberType {
var sign: Self { return (self > 0).as01() - (self < 0).as01() }
}


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

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

[Charlie Monroe via swift-evolution]

> If the URL path property was defined not to return ‘String?' but to return 
> ‘Any’ (which can of course hold an Optional just like it can hold any other 
> type) what would the proposed compiler behavior be?

No warning. Since you cast Optional to Any, no warning can even be issued since 
that will eventually be determined during runtime, there's not much the 
compiler can do here.

Only if you returned `Any?` - which then Optional, anyway.

> The actual definition of debugDescription is discouraged from being called by 
> user code. This method also only coincidentally provides the identical text 
> as string interpolation today. Are you proposing to change the standard 
> library documentation to say that users should be calling debugDescription in 
> this scenario, and change optional to define what its implementation of 
> debugDescription returns?

What about adding .description (i.e. comply to CustomStringConvertible) and 
calling .description instead? I'll update the proposal to match this.

> If I have a type which I don’t want used in String interpolation, I would 
> like to mark it as giving a warning. Examples would be a Result type for 
> representing success or error from a function call, or a future type to 
> represent a task dispatched to another thread that may or may not have 
> finished and returned a result yet. Do you propose a way for me to have the 
> compiler warn if I accidentally have these types used in string interpolation 
> as well, or do I only benefit from optional as a special case.

I'd prefer to leave the Optional as a special case handled by the language, but 
you can deprecate interpolation for custom types yourself - see below.

> And finally, I can have my own type which implements 
> StringInterpolationConvertible. Examples might be 
> - LocalizableString type which maps the provided string to correct user 
> output through a localization table
> - DebugString for debug logging that uses CustomDebugStringConvertible when 
> available to represent types
> - an HtmlEscapedString which deals with making values that don’t implement 
> the HtmlEscaped protocol HTML-safe, including Strings
> 
> How would I get the optional usage defined for String type interpolation for 
> these cases. DebugString would like to represent optionals as today, 
> LocalizableString would like to capture optionals so that it can switch to a 
> specific internationalized message in this case, and HtmlEscapedString would 
> like the same behavior you are proposing for String.

The deprecation doesn't necessarily need to be handled by the compiler itself, 
but can be enforced by the following code:

extension String {

@available(*, deprecated, message="Interpolation of optionals is 
deprecated.")
init(stringInterpolationSegment segment: Optional) {
// fatalError()
}

}


With this kind of implementation, you get the warnings, however, without the 
compiler support you won't get the Fix-It for adding .description - I'm not 
sure the renamed= part of the attribute can be abused to do this, but I don't 
think it can be.

And in a similar fashion, you can deprecate the Optional or any other kind on 
your other strings and keep them on DebugString.

Charlie

> -DW
> 

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams via swift-evolution]

on Sun May 22 2016, Matthew Johnson  wrote:

> Are you sure that is Sean’s entire point? I take more away from it than that.
> Look at slide 13 here:
> https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf
>
> “The shared structure also breaks our ability to reason locally about code”. 
>
> But I know you agree with that as well as you indicated just up thread. 
>
> It sounds like the only remaining point of possible disagreement is whether
> “can’t reach shared mutable state” is a reasonable constraint to place on 
> types
> in generic code.

Here's what Sean sent me this morning:

> Hi Dave,
> 
> I've now had several people send me this transcript. I'm not seeing
> 
> Although I'm sure you know this - the short definition of regular is:
> 
>   copies are equal and logically disjoint.
> 
> Logically disjoint means that modifications to one copy do not modify
> other copies. It does not mean "no sharing" - sharing of an immutable
> part, a copy-on-write part (immutable when shared) or a part which is
> outside the definition of equality (such as a cache) are all
> allowed. We can write out all the axioms for a regular type if that
> would help. I do not know what the axioms of a "pure value" are, or
> how they would differ from this definition. Typically in functional
> programming (where "pure" is used to refer to functions that have no
> side effects) a value is not mutable and so the notion of disjoint
> does not come into question and there is typically significant
> sharing.
> 
> For "pure value" to be a useful concept we need an instance of a
> model, an algorithm that relies on the additional requirements, and
> the axioms that define it. From the thread it seems as if the
> definition is something like "copies are equal and physically
> disjoint." I'm not sure if there is something else people are trying
> to say along the lines that all parts are included in equality. I do
> not see any compelling evidence in the description that there are
> useful algorithms that rely on such attributes. Note that concepts are
> about enabling additional algorithms, including for efficiency.
> 
> [ Feel free to quote this back to the list - I can be easily reached
> at spar...@adobe.com if people have questions instead of speculating
> about what I did, or did not, mean in my talks. ]
> 
> Sean

...and now, I really need to get back to work on *my* talk for WWDC.

Cheers,

-- 
Dave

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

Re: [swift-evolution] Proposal SE-0009 Reconsideration

[Charles Srstka via swift-evolution]

As another colorblind developer, this kind of is an issue. While I *can* 
discern colors, the only one that sticks out strongly is blue. If you’ve got 
reds, greens, browns, or oranges, my experience will be on a continuum from “I 
think that’s red?” in the best case, “I can figure this out if I 
accessibility-zoom it into a huge color patch” in the middle, and “Let me get 
out DigitalColorMeter” in the worst case. Purple, of course, is very hard to 
distinguish from blue. I guess grey is distinguishable, if you consider it a 
color. Other than that, syntax highlighting doesn’t do a lot for me.

Plus, I might end up having to use a different source editor sometimes, 
particularly when I’m doing a large refactor and Xcode is stuck in its 
“SourceKitService crash every time two characters are typed” thing. I’d really 
rather have things differentiable in the language itself rather than relying on 
external crutches.

Charles

> On May 23, 2016, at 11:43 AM, Jeff Kelley via swift-evolution 
>  wrote:
> 
> As a colorblind developer, this isn’t really an issue. The vast majority of 
> colorblind people can discern colors. As long as the IDE allows you to 
> customize which colors it displays, you can find a palette that will work 
> with your eyes (for my type of colorblindness, for instance, I have 
> difficulty differentiating blue and purple, so I wouldn’t use both in my 
> syntax highlighting color scheme). As long as color isn’t the only thing 
> differentiating on-screen elements, adding colors to syntax highlighting is 
> beneficial even to us colorblind developers. :)

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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

Yes, this is probably better founded.

Right now Swift doesn't have a blessed nothing type, the closest you can
get is enum Nothing { }, and that type doesn't participate in subtyping
relationships (it's not really a Bottom type like Scala's). Proposing such
an expansion to the type system is beyond the scope of this proposal,
although the "associated types" section should certainly be written such
that generalizing it would be trivial if Swift did get contravariant types
and a Bottom type.

Austin

On Mon, May 23, 2016 at 11:24 AM, Thorsten Seitz 
wrote:

>
> Am 23.05.2016 um 18:08 schrieb Austin Zheng :
>
>
> I think that *all* methods should be available - at least in principle -
> with associated types
> - replaced by their upper bounds (i.e. Any if no constraints have been
> given either by the protocol definition itself or th existential) if in
> covariant position and
> - replaced by their lower bounds if in contravariant position
>
> As it is not possible to define lower bounds in Swift, the lower bounds
> are always the bottom type (called `Nothing` in Swift and not be confused
> with optionals). The bottom type has no members and therefore a method
> referencing that type cannot be called and is effectively not available.
>
>
> Thanks for the feedback! So methods that have associated types in
> contravariant position would have those types be Nothing, unless there was
> a concrete type bound to that associated type in the Any's where clause?
>
> Example
>
> protocol MyProtocol {
>   associatedtype AssocType1
>   associatedtype AssocType2
>   func foo(x: AssocType1, y: AssocType2)
> }
>
> let a : Any
> // on 'a', foo is exposed as 'foo(x: Nothing, y: Nothing)', and can thus
> not be called
>
> let b : Any
> // on 'b', foo is exposed as 'foo(x: Int, y: Nothing)' and still can't be
> called
>
> let c : Any
> // on 'c', foo is exposed as 'foo(x: Int, y: String)', and can therefore
> be called
>
> Let me know if this is what you had in mind.
>
>
> Yes, that’s what I had in mind.
>
> IMHO this would make for simple rules and if Swift might one day get the
> ability to specify lower bounds this would easily fit in (I don’t know how
> useful that would be in reality, but I think Scala allows the declaration
> of lower bounds).
>
> -Thorsten
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enhanced existential types proposal discussion

[Thorsten Seitz via swift-evolution]

> Am 23.05.2016 um 18:08 schrieb Austin Zheng :
> 
>> 
>> I think that *all* methods should be available - at least in principle - 
>> with associated types 
>> - replaced by their upper bounds (i.e. Any if no constraints have been given 
>> either by the protocol definition itself or th existential) if in covariant 
>> position and 
>> - replaced by their lower bounds if in contravariant position
>> 
>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>> always the bottom type (called `Nothing` in Swift and not be confused with 
>> optionals). The bottom type has no members and therefore a method 
>> referencing that type cannot be called and is effectively not available.
>> 
> 
> Thanks for the feedback! So methods that have associated types in 
> contravariant position would have those types be Nothing, unless there was a 
> concrete type bound to that associated type in the Any's where clause?
> 
> Example
> 
> protocol MyProtocol {
>   associatedtype AssocType1
>   associatedtype AssocType2
>   func foo(x: AssocType1, y: AssocType2)
> }
> 
> let a : Any
> // on 'a', foo is exposed as 'foo(x: Nothing, y: Nothing)', and can thus not 
> be called
> 
> let b : Any
> // on 'b', foo is exposed as 'foo(x: Int, y: Nothing)' and still can't be 
> called
> 
> let c : Any
> // on 'c', foo is exposed as 'foo(x: Int, y: String)', and can therefore be 
> called
> 
> Let me know if this is what you had in mind.

Yes, that’s what I had in mind. 

IMHO this would make for simple rules and if Swift might one day get the 
ability to specify lower bounds this would easily fit in (I don’t know how 
useful that would be in reality, but I think Scala allows the declaration of 
lower bounds).

-Thorsten

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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 23, 2016, at 12:26 PM, Robert Widmann  wrote:
> 
> The fun part about Nothing (⊥) is that it does have one constructor: crashing.

Ok, but where does the part about calling bottom 'Nothing' in Swift come from?  
This is the first I've heard of the name 'Nothing' in Swift.

> 
> ~Robert Widmann
> 
> 2016/05/23 10:17、Matthew Johnson via swift-evolution 
>  のメッセージ:
> 
>> 
>>> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution 
 :
 
 I agree; the difference between protocols with and without associated 
 types has been an endless source of confusion for a lot of people.
 
 Speaking of which, for those who care I rewrote the draft proposal to 
 attempt a much more rigorous treatment of the semantics of the generalized 
 existential, including a discussion about existential type equivalence and 
 subtyping. It would be nice to see people poke holes in my logic so I can 
 patch them up. 
 https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>>> 
>>> I think that *all* methods should be available - at least in principle - 
>>> with associated types 
>>> - replaced by their upper bounds (i.e. Any if no constraints have been 
>>> given either by the protocol definition itself or th existential) if in 
>>> covariant position and 
>>> - replaced by their lower bounds if in contravariant position
>>> 
>>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>>> always the bottom type (called `Nothing` in Swift and not be confused with 
>>> optionals). The bottom type has no members and therefore a method 
>>> referencing that type cannot be called and is effectively not available.
>> 
>> Called `Nothing` in Swift?  Where do you get that?  `func foo(s: Nothing) 
>> {}` gives me “use of undeclared type `Nothing`”.  If Swift had a bottom type 
>> wouldn’t we be able to declare a function accepting an argument of type 
>> `Nothing` (we could just never call it because we couldn’t construct an 
>> argument).
>> 
>>> 
>>> -Thorsten 
>>> 
 
 Austin
 
>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
>>  wrote:
>> 
>> 
>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> I agree with this. If we're certain we should reskin protocol<> as 
>> Any<>, we should frontload that change—in addition to affecting source 
>> code, it'd also influence the runtime behavior of type printing/parsing, 
>> which can't be statically migrated in the future. I think any discussion 
>> of extending existentials has to be considered out of scope for Swift 3, 
>> though, so the Any rename deserves its own proposal.
>> 
>> -Joe
> 
> 
> Its really unfortunate that the generics work is probably going to be 
> deferred. When you really dive in to protocol-oriented programming and 
> designing frameworks to be native Swift (taking advantage of Swift 
> features) the existential problem comes up a lot and leads to sub-optimal 
> designs, abandonment of type safety, or gobs of boilerplate.  
> 
> 
> Russ
> 
> ___
> 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] Enhanced existential types proposal discussion

[Thorsten Seitz via swift-evolution]

> Am 23.05.2016 um 19:17 schrieb Matthew Johnson :
> 
>> 
>> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution 
>> >:
>> 
>>> I agree; the difference between protocols with and without associated types 
>>> has been an endless source of confusion for a lot of people.
>>> 
>>> Speaking of which, for those who care I rewrote the draft proposal to 
>>> attempt a much more rigorous treatment of the semantics of the generalized 
>>> existential, including a discussion about existential type equivalence and 
>>> subtyping. It would be nice to see people poke holes in my logic so I can 
>>> patch them up. 
>>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>>>  
>>> 
>> I think that *all* methods should be available - at least in principle - 
>> with associated types 
>> - replaced by their upper bounds (i.e. Any if no constraints have been given 
>> either by the protocol definition itself or th existential) if in covariant 
>> position and 
>> - replaced by their lower bounds if in contravariant position
>> 
>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>> always the bottom type (called `Nothing` in Swift and not be confused with 
>> optionals). The bottom type has no members and therefore a method 
>> referencing that type cannot be called and is effectively not available.
> 
> Called `Nothing` in Swift?  Where do you get that?  `func foo(s: Nothing) {}` 
> gives me “use of undeclared type `Nothing`”.  If Swift had a bottom type 
> wouldn’t we be able to declare a function accepting an argument of type 
> `Nothing` (we could just never call it because we couldn’t construct an 
> argument).

oops, sorry, I had wanted to type „called `Nothing` in Scala“ :-)

-Thorsten


> 
>> 
>> -Thorsten 
>> 
>>> 
>>> Austin
>>> 
 On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
 > wrote:
 
 
> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
> > wrote:
> 
> I agree with this. If we're certain we should reskin protocol<> as Any<>, 
> we should frontload that change—in addition to affecting source code, 
> it'd also influence the runtime behavior of type printing/parsing, which 
> can't be statically migrated in the future. I think any discussion of 
> extending existentials has to be considered out of scope for Swift 3, 
> though, so the Any rename deserves its own proposal.
> 
> -Joe
 
 
 Its really unfortunate that the generics work is probably going to be 
 deferred. When you really dive in to protocol-oriented programming and 
 designing frameworks to be native Swift (taking advantage of Swift 
 features) the existential problem comes up a lot and leads to sub-optimal 
 designs, abandonment of type safety, or gobs of boilerplate.  
 
 
 Russ
 
 ___
 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] Proposal: Deprecate optionals in string interpolation

[David Waite via swift-evolution]

I’m still unclear what the answers to my questions below would be. I’ll restate 
them below.

>>> 1. If I was printing a protocol type that Optional supports, such as Any, 
>>> would I get a warning?

Since this may have been misunderstood, let me phrase it a different way.

If the URL path property was defined not to return ‘String?' but to return 
‘Any’ (which can of course hold an Optional just like it can hold any other 
type) what would the proposed compiler behavior be?

>>> 2. I believe debugDescription is discouraged from being called directly 
>>> [from CustomDebugStringConvertible docs]. Perhaps String(reflecting: ) 
>>> instead, although such debug description behavior could cause different 
>>> results if you were expecting this fixit to apply to Any types.

The actual definition of debugDescription is discouraged from being called by 
user code. This method also only coincidentally provides the identical text as 
string interpolation today. Are you proposing to change the standard library 
documentation to say that users should be calling debugDescription in this 
scenario, and change optional to define what its implementation of 
debugDescription returns?

>>> 3. How would I have the ability to opt into this behavior for my own types 
>>> (such as Result or Future)?
>>> 4. How would I opt in/out of this behavior for my own 
>>> StringInterpolationConvertible implementations?
>> 
>> This is not about customizing the interpolation but about warning the user 
>> when using optionals in string interpolation to prevent from such mistakes 
>> as above with the URL. This is more common than one would think and 
>> sometimes is hard to spot. I'm sorry if I misunderstood you questions.

If I have a type which I don’t want used in String interpolation, I would like 
to mark it as giving a warning. Examples would be a Result type for 
representing success or error from a function call, or a future type to 
represent a task dispatched to another thread that may or may not have finished 
and returned a result yet. Do you propose a way for me to have the compiler 
warn if I accidentally have these types used in string interpolation as well, 
or do I only benefit from optional as a special case.

And finally, I can have my own type which implements 
StringInterpolationConvertible. Examples might be 
- LocalizableString type which maps the provided string to correct user output 
through a localization table
- DebugString for debug logging that uses CustomDebugStringConvertible when 
available to represent types
- an HtmlEscapedString which deals with making values that don’t implement the 
HtmlEscaped protocol HTML-safe, including Strings

How would I get the optional usage defined for String type interpolation for 
these cases. DebugString would like to represent optionals as today, 
LocalizableString would like to capture optionals so that it can switch to a 
specific internationalized message in this case, and HtmlEscapedString would 
like the same behavior you are proposing for String.

-DW

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

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 23, 2016, at 11:19 AM, Patrick Smith  wrote:
> 
> I just want to highlight the Photoshop history example. I agree you’d want as 
> much state and memory shared between steps in the history.
> 
> However, I see nothing wrong with having pointers to pixel buffer, and that 
> affecting the ‘purity’ of the state.

I don’t have a problem with pointers to pixel buffers.  What I have a problem 
with is pointers to shared mutable state.  All you need to do is implement a 
value type that wraps the pointer and performs CoW before updating.  Now you 
have an efficient pixel buffer that is a pure value type.

> The way Photoshop’s history is implemented, is every image is broken up into 
> tiles. Changes are recorded only within touched tiles. 
> (http://www.photoshopforphotographers.com/CC_2013/Help_guide/tp/History_palette.html
>  
> )
>  This improves memory usage compared to a single pixel buffer.

Yep, I know how it is implemented and believe I described this upthread.  

> With a graphics programming workflow, say where a background thread or the 
> GPU is involved, the contents of those pixel buffers are going to change 
> independently to the history stack. I think there would no problem for the 
> history steps to have pointers to their mutable pixel buffers. Once the 
> thread/GPU has finished processing changes within a step’s pixel buffer, it 
> is ‘sealed’ say with a flag, and can’t be mutated later.

If you don’t know what the new value is synchronously then it certainly isn’t 
quite as simple.  But you can still encapsulate this in a type that holds the 
pointer, performs CoW when necessary, and ensures that the pixel buffer isn’t 
written to other than by the job that is processing the pixels for this step.  
The physical pixels are mutated, but the “logical value” isn’t.  The logical 
value is the result of a pure function “applyEditToPixels(oldPixels)” which is 
captured by the new step in the history.  The mutation is tightly encapsulated 
as an implementation detail.  

I agree that we need to allow for implementation details like this.  But we 
should find other ways when possible.  And we should probably have to be 
explicitly clear about our intent if we want to implement a pure value which is 
hiding an implementation like this.

> 
> The only other way I could think of is for each history step to use UUIDs to 
> reference tile pixel buffers, and manage a separate map of [UUID: 
> PixelBuffer]. Possibly this approach might have other benefits, but I think 
> it doesn’t differ practically in ‘purity’ of state vs one state tree 
> involving pointers. The purity is from the point of view of the programmer, 
> where they know their system is purely additive.
> 
> The guarantee is in the system the programmer has created. Not allowing 
> pointers to carefully managed mutable state is too rigid.

I am not suggesting they shouldn’t be allowed.  I absolutely agree that they 
*should* be allowed!  This is one reason why I love Swift!  It blends 
functional and imperative in a very nice way.

It seems likely that we will eventually have ownership semantics of some kind 
in Swift.  When we have that we will have the ability to have unique references 
to mutable state.  I have no problem viewing that as a pure value, because the 
mutation is local.  It is really no different than a `var Int`, it is just 
indirect.

However, if we share references to the mutable state then we are introducing 
potential for non-local mutation.  I believe it is extremely useful to have 
*parts* of our program that don’t allow for this, and ideally get the compilers 
help with ensuring this.

I hope that doesn’t seem like to rigid a request!  I want *choice* not rigidity!

> 
> 
>> On 23 May 2016, at 5:12 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 22, 2016, at 12:04 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> on Mon May 16 2016, Matthew Johnson >> > wrote:
>>> 
> On May 15, 2016, at 2:01 PM, Dave Abrahams
> > wrote:
> 
> 
> on Fri May 13 2016, Matthew Johnson  
> >> 
> wrote:
> 
 
>> Sent from my iPad
>> 
>>> On May 13, 2016, at 9:12 AM, Dave Abrahams >> > wrote:
>>> 
>>> 
 on Mon May 09 2016, Matthew Johnson >>> > wrote:
 
 My claim is that substituting the constraint of “it has value
 semantics,” while presumably looser than the PureValue 

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

[Matthew Johnson via swift-evolution]

> On May 23, 2016, at 9:22 AM, Dave Abrahams  wrote:
> 
> 
> on Sun May 22 2016, Matthew Johnson  > wrote:
> 
>>> On May 22, 2016, at 3:42 PM, Dave Abrahams via swift-evolution
>>>  wrote:
>>> 
>>> 
>>> on Sun May 22 2016, Matthew Johnson  wrote:
>>> 
 What I am arguing for is the ability to distinguish aggregates which
 are logically isolated from aggregates which contain salient
 references to shared mutable state. 
>>> 
>>> Everything with value semantics is logically isolated in that way.
>> 
>> Array has salient references whose referent is shared mutable
>> state.  The references are salient attributes. You’re saying the
>> referent doesn’t matter because the boundary of the value stops at the
>> reference.  
> 
> I'm saying you can define things that way, and it helps to make the
> model for generic programming coherent.  Without something like this, it
> becomes almost impossible to specify the behavior of generic components
> in an understandable way without simultaneously preventing the use of
> reference values as simple object identities, which *are* values.  As I
> mentioned elsewhere, we could force users to wrap these reference values
> to produce something that doesn't have easily identifiable reference
> semantics, but the requirement of your `PureValue` that there should be
> *no way* to derive access to the referenced instance from the wrapped
> reference is too limiting.
> 
>> I’m saying it does matter in that it means the aggregate is no longer
>> logically isolated because shared mutable state is reachable through
>> the aggregate.  Therefore it is not isolated in that way that I was
>> intending to describe.
> 
> This, again, is a matter of your mental model.  I do think it's
> reasonable to say that—especially in Swift where reference-ness is often
> syntactically invisible—asking people to adopt a mental model that
> *directly* treats references as values is simply unrealistic.  In that
> case, using some kind of wrapper to represent object identity might be
> the only practical way to do this.

I think the lack of syntax is a good point.  I have wondered how this would 
play out in Swift.

However, I think it goes deeper than just being syntactically invisible.  If 
Swift used C-like pointer syntax that would give us a syntactic distinction but 
not a semantic one.

Consider your `Set` example.  In this case, maybe you really do 
just care about object identity so you can test set membership.  In this case 
you really are just viewing the references as values.  In this case you really 
do view `Set` as a pure value.

Consider another example - an `Order` with an `Array`.  In this case, 
you are looking at the array as a part of an aggregate.  You don’t care about 
the values of the references at all, except as a means to get you the object.  
In this case `Array` isn’t a pure value (if `LineItem` is a type with 
reference semantics).

If we simply referred to all reference types with `*DrawableObject` syntax we 
would have to do that in both `Set<*DrawableObject>` and `Array<*LineItem>`.  
The semantic distinction isn’t captured.

However, if we use an opaque wrapper type like you suggest we actually *can* 
capture the distinction.  We can say `Set`.  It would 
be perfectly acceptable to me to view this as a pure value because it is clear 
that you are only looking at the value of the reference, not actually following 
the reference.  And if we really needed to include “unsafeDereference” or 
something like that for performance reasons I could probably live with that.  
At least your intention is explicit.  If desired we could even introduce 
syntactic sugar for this wrapper like we have for `Optional`, `Array`, and 
`Dictionary` so you can talk about it more concisely.


> 
 To be honest, I am really struggling to understand why this
 distinction seems unimportant to you.
>>> 
>>> The non-exposure of shared mutable state is a hugely important
>>> property of well-encapsulated design.  However, I don't believe it's
>>> appropriate to represent that with a protocol, because I don't
>>> believe there exist any generic components whose correctness depends
>>> on it.
>> 
>> Do you believe it is appropriate to represent this in some other way
>> that allows us to state architectural intent and introduce constraints
>> for the purpose of structuring a large code base?
> 
> Sure, if it makes your life better, you should define it; I just don't
> see yet that it has any place in the standard library.  It is a
> principle of generic programming that protocols (concepts) are
> *discovered* through a specific process.  In the standard library, we
> don't define a new protocol until we have identified a family of
> concrete components that can be generalized based that protocol and
> whose correctness depends on the protocol's constraints.

I hope I am 

Re: [swift-evolution] [Pitch] 'Double modulo' operator

[Adam Nemecek via swift-evolution]

Would you want to make this a function? Or an operator but a different one?

On Mon, May 23, 2016 at 7:30 AM, Stephen Canon  wrote:

> I’m not really sold on the `%%` spelling, but I think the operation itself
> is worth exposing.  This is the remainder of a “flooring” division (as
> opposed to the C-family “truncating” division[1]).  If we do provide it, we
> should also provide the accompanying divide operation.
>
> – Steve
>
> [1] there are several other ways to define division beyond these two:
> remainder is always positive, remainder is closest to zero, etc.
> Truncating and flooring division are the most common by a wide margin,
> however.
>
> On May 21, 2016, at 4:22 PM, Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I think that Swift could use the 'double modulo' operator which is for
> example in CoffeeScript (some discussion can be found here
> https://github.com/jashkenas/coffeescript/issues/1971).
>
> This operator, unlike normal modulo, takes sign from the divisor, not the
> dividend e.g. -10 % 3 == -1, but -10 %% 3 == 2.
>
> In practice, this operator is useful for 'cyclical' indexing. For example,
> it would be useful for calculating the real index into a collection when we
> are using an index outside of the range of valid indices and could be used
> to index into a collection using a negative index à la Python and Ruby
> (where [1,2,3,4][-1] == 4).
>
>
> The implementation would probably be something along these lines:
>
> infix operator %% {
>   associativity left
>   precedence 150
> }
>
> func %%(lhs:T, rhs:T) -> T {
>   return (lhs % rhs + rhs) % rhs
> }
>
> If accepted, this could be later incorporated into a method or operator
> that works directly with collections using their count property.
> Maybe the syntax could be something like [1,2,3,4] %% -1 == 4.
>
> Ideas, suggestions?
> ___
> 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] Proposal: Automatic initializer generation

[L. Mihalkovic via swift-evolution]

> On May 23, 2016, at 7:24 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On May 23, 2016, at 10:52 AM, Kevin Nattinger via swift-evolution 
>>  wrote:
>> 
>> Discussed last month 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html
>> And (linked from that thread) last year 
>> http://article.gmane.org/gmane.comp.lang.swift.evolution/727
>> 
>> I think it’s a good idea, but discussion seems to have just petered out 
>> without a formal proposal both times. 

IMHO the proposals were on a collision course with yet untouched parts of the 
language. 

> 
> This didn’t peter out.  My opinion on this topic evolved throughout the 
> review.  The perspective I came to is that the best approach may require 
> changes that are outside the scope of Swift 3.  I expect this to come up 
> again during the Swift 4 conversation.
> 
>> 
>> How about we just apply the struct auto-init behavior to classes? It’s nice 
>> and simple, and already in the language.
>> 
>>> On May 23, 2016, at 7:29 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> 
>>> A lot of initializers tediously assign values to variables which results in 
>>> a lot of code such as self.variable = arg1 (or even worse variable = 
>>> variable), mostly for classes that are meant to just encapsulate several 
>>> values.
>>> 
>>> I propose adding auto keyword (to be discussed - anyone has a better name 
>>> in mind?), which would automatically assign same-named variables. Example:
>>> 
>>> class User {
>>>var name: String
>>>var password: String
>>>
>>>init(auto name: String, auto password: String) {
>>>// No assignment required, the variables will be automatically 
>>> assigned.
>>>// Perform additional init stuff here.
>>>}
>>> }
>>> 
>>> This would, of course, work only if the argument has the same name as a 
>>> stored variable on the class.
>>> 
>>> Additionally, if the class is root, or the superclass has an initializer 
>>> that takes no arguments, I propose adding @auto_init annotation, which 
>>> would generate a default initializer, similar to what is done for structs:
>>> 
>>> @auto_init
>>> class User {
>>>var name: String
>>>var password: String
>>> }
>>> 
>>> Normally, such class would be illegal since it would have no accessible 
>>> initializers. The annotation could specify the access control as well: 
>>> @auto_init(private), @auto_init(internal), @auto_init(public).
>>> 
>>> If the class isn't root, but inherits from an object that has an 
>>> initializer that takes no arguments (e.g. NSObject), this would be allowed 
>>> as well and the initializer with no arguments would be called on super.
>>> 
>>> Any thoughts on this? Sorry, if this has been already discussed.
>>> 
>>> Charlie
>>> 
>>> ___
>>> 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] Proposal SE-0009 Reconsideration

[L. Mihalkovic via swift-evolution]

> On May 23, 2016, at 7:26 PM, David Sweeris  wrote:
> 
> 
> On May 23, 2016, at 11:24, Krystof Vasa via swift-evolution 
>  wrote:
> 
>>> The problem can also be easily mitigated by having the IDE use a different 
>>> color to display a variable based on where it was defined (eclipse come to 
>>> mind as an example). This is something the brain naturally notices without 
>>> paying any conscious attention.
>> 
>> Tell that to the colorblind :)
> 
> Dunno about other IDEs, but Xcode's syntax highlighting can change the size, 
> typeface (bold, italic, etc), and even the font. You can make instance 
> variables show up as 24pt comic sans, if you want. You can’t do polkadot, 
> though… apparently that’s going too far.
> 

Issue is SourceKit may not have the scope of an identifier (was not there last 
time I looked), just the fact that it was an identifier (i looked a while ago 
mind you)


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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Robert Widmann via swift-evolution]

The fun part about Nothing (⊥) is that it does have one constructor: crashing.

~Robert Widmann

2016/05/23 10:17、Matthew Johnson via swift-evolution 
 のメッセージ:

> 
>> On May 23, 2016, at 10:57 AM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution 
>>> :
>>> 
>>> I agree; the difference between protocols with and without associated types 
>>> has been an endless source of confusion for a lot of people.
>>> 
>>> Speaking of which, for those who care I rewrote the draft proposal to 
>>> attempt a much more rigorous treatment of the semantics of the generalized 
>>> existential, including a discussion about existential type equivalence and 
>>> subtyping. It would be nice to see people poke holes in my logic so I can 
>>> patch them up. 
>>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>> 
>> I think that *all* methods should be available - at least in principle - 
>> with associated types 
>> - replaced by their upper bounds (i.e. Any if no constraints have been given 
>> either by the protocol definition itself or th existential) if in covariant 
>> position and 
>> - replaced by their lower bounds if in contravariant position
>> 
>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>> always the bottom type (called `Nothing` in Swift and not be confused with 
>> optionals). The bottom type has no members and therefore a method 
>> referencing that type cannot be called and is effectively not available.
> 
> Called `Nothing` in Swift?  Where do you get that?  `func foo(s: Nothing) {}` 
> gives me “use of undeclared type `Nothing`”.  If Swift had a bottom type 
> wouldn’t we be able to declare a function accepting an argument of type 
> `Nothing` (we could just never call it because we couldn’t construct an 
> argument).
> 
>> 
>> -Thorsten 
>> 
>>> 
>>> Austin
>>> 
> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> I agree with this. If we're certain we should reskin protocol<> as Any<>, 
> we should frontload that change―in addition to affecting source code, 
> it'd also influence the runtime behavior of type printing/parsing, which 
> can't be statically migrated in the future. I think any discussion of 
> extending existentials has to be considered out of scope for Swift 3, 
> though, so the Any rename deserves its own proposal.
> 
> -Joe
 
 
 Its really unfortunate that the generics work is probably going to be 
 deferred. When you really dive in to protocol-oriented programming and 
 designing frameworks to be native Swift (taking advantage of Swift 
 features) the existential problem comes up a lot and leads to sub-optimal 
 designs, abandonment of type safety, or gobs of boilerplate.  
 
 
 Russ
 
 ___
 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] Proposal: Automatic initializer generation

[Matthew Johnson via swift-evolution]

> On May 23, 2016, at 10:52 AM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> Discussed last month 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html
> And (linked from that thread) last year 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/727
> 
> I think it’s a good idea, but discussion seems to have just petered out 
> without a formal proposal both times. 

This didn’t peter out.  My opinion on this topic evolved throughout the review. 
 The perspective I came to is that the best approach may require changes that 
are outside the scope of Swift 3.  I expect this to come up again during the 
Swift 4 conversation.

> 
> How about we just apply the struct auto-init behavior to classes? It’s nice 
> and simple, and already in the language.
> 
>> On May 23, 2016, at 7:29 AM, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> A lot of initializers tediously assign values to variables which results in 
>> a lot of code such as self.variable = arg1 (or even worse variable = 
>> variable), mostly for classes that are meant to just encapsulate several 
>> values.
>> 
>> I propose adding auto keyword (to be discussed - anyone has a better name in 
>> mind?), which would automatically assign same-named variables. Example:
>> 
>> class User {
>>  var name: String
>>  var password: String
>>  
>>  init(auto name: String, auto password: String) {
>>  // No assignment required, the variables will be automatically 
>> assigned.
>>  // Perform additional init stuff here.
>>  }
>> }
>> 
>> This would, of course, work only if the argument has the same name as a 
>> stored variable on the class.
>> 
>> Additionally, if the class is root, or the superclass has an initializer 
>> that takes no arguments, I propose adding @auto_init annotation, which would 
>> generate a default initializer, similar to what is done for structs:
>> 
>> @auto_init
>> class User {
>>  var name: String
>>  var password: String
>> }
>> 
>> Normally, such class would be illegal since it would have no accessible 
>> initializers. The annotation could specify the access control as well: 
>> @auto_init(private), @auto_init(internal), @auto_init(public).
>> 
>> If the class isn't root, but inherits from an object that has an initializer 
>> that takes no arguments (e.g. NSObject), this would be allowed as well and 
>> the initializer with no arguments would be called on super.
>> 
>> Any thoughts on this? Sorry, if this has been already discussed.
>> 
>> Charlie
>> 
>> ___
>> 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] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

> On May 23, 2016, at 11:08 AM, Austin Zheng via swift-evolution 
>  wrote:
> 
>> 
>> I think that *all* methods should be available - at least in principle - 
>> with associated types 
>> - replaced by their upper bounds (i.e. Any if no constraints have been given 
>> either by the protocol definition itself or th existential) if in covariant 
>> position and 
>> - replaced by their lower bounds if in contravariant position
>> 
>> As it is not possible to define lower bounds in Swift, the lower bounds are 
>> always the bottom type (called `Nothing` in Swift and not be confused with 
>> optionals). The bottom type has no members and therefore a method 
>> referencing that type cannot be called and is effectively not available.
>> 
> 
> Thanks for the feedback! So methods that have associated types in 
> contravariant position would have those types be Nothing, unless there was a 
> concrete type bound to that associated type in the Any's where clause?
> 
> Example
> 
> protocol MyProtocol {
>   associatedtype AssocType1
>   associatedtype AssocType2
>   func foo(x: AssocType1, y: AssocType2)
> }
> 
> let a : Any
> // on 'a', foo is exposed as 'foo(x: Nothing, y: Nothing)', and can thus not 
> be called
> 
> let b : Any
> // on 'b', foo is exposed as 'foo(x: Int, y: Nothing)' and still can't be 
> called
> 
> let c : Any
> // on 'c', foo is exposed as 'foo(x: Int, y: String)', and can therefore be 
> called
> 
> Let me know if this is what you had in mind.

>From the standpoint of the interface of the existential these methods are not 
>callable.  That is the most important point and your proposal already covers 
>this.

If contravariance were ever introduced into Swift we would want to include 
updates to existentials in the process of adding it.


> 
> Austin
> 
>> -Thorsten 
> 
> ___
> 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] Proposal SE-0009 Reconsideration

[Jeff Kelley via swift-evolution]

As a colorblind developer, this isn’t really an issue. The vast majority of 
colorblind people can discern colors. As long as the IDE allows you to 
customize which colors it displays, you can find a palette that will work with 
your eyes (for my type of colorblindness, for instance, I have difficulty 
differentiating blue and purple, so I wouldn’t use both in my syntax 
highlighting color scheme). As long as color isn’t the only thing 
differentiating on-screen elements, adding colors to syntax highlighting is 
beneficial even to us colorblind developers. :)


Jeff Kelley

slauncha...@gmail.com | @SlaunchaMan  | 
jeffkelley.org 

Check out Developing for Apple Watch, Second Edition 
,
 now in print!

> On May 23, 2016, at 12:24 PM, Krystof Vasa via swift-evolution 
>  wrote:
> 
>> The problem can also be easily mitigated by having the IDE use a different 
>> color to display a variable based on where it was defined (eclipse come to 
>> mind as an example). This is something the brain naturally notices without 
>> paying any conscious attention.
> 
> Tell that to the colorblind :)
> 
>> 
>>> -- E
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Automatic initializer generation

[Charlie Monroe via swift-evolution]

Thanks for the links.

You can't apply auto-init behavior to all classes since it gets a bit more 
complicated once the only initializers available take some arguments - the 
compiler can't know what to pass where to super, so it would need to chain the 
arguments, which would lead to initializers with dozens of arguments. So in 
such case the auto-init is IMHO out of question.

The variant that I'm suggesting is simplified and restricted only to classes 
that either do not inherit from anything, or have an initializer that takes no 
arguments - which makes the issue much simpler than previously suggested.

I dislike the syntax of the previous proposal

init (self.a: Int, self.b: String) {
   //...
}

where you specify self.a: Int - IMHO this should be done using a keyword that 
automates it and I'd allow it only for arguments that match a variable on the 
instance. Or perhaps allowing something like auto(xyz) to specify the variable? 
Or #auto(xyz)?

This seems a bit more readable to me:

init (auto a: Int, auto b: String) {
   //...
}

If there is still some interest in making this a proposal, I can write it up.

Charlie


> On May 23, 2016, at 5:52 PM, Kevin Nattinger  wrote:
> 
> Discussed last month 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html
> And (linked from that thread) last year 
> http://article.gmane.org/gmane.comp.lang.swift.evolution/727
> 
> I think it’s a good idea, but discussion seems to have just petered out 
> without a formal proposal both times. 
> 
> How about we just apply the struct auto-init behavior to classes? It’s nice 
> and simple, and already in the language.
> 
>> On May 23, 2016, at 7:29 AM, Charlie Monroe via swift-evolution 
>>  wrote:
>> 
>> A lot of initializers tediously assign values to variables which results in 
>> a lot of code such as self.variable = arg1 (or even worse variable = 
>> variable), mostly for classes that are meant to just encapsulate several 
>> values.
>> 
>> I propose adding auto keyword (to be discussed - anyone has a better name in 
>> mind?), which would automatically assign same-named variables. Example:
>> 
>> class User {
>>  var name: String
>>  var password: String
>>  
>>  init(auto name: String, auto password: String) {
>>  // No assignment required, the variables will be automatically 
>> assigned.
>>  // Perform additional init stuff here.
>>  }
>> }
>> 
>> This would, of course, work only if the argument has the same name as a 
>> stored variable on the class.
>> 
>> Additionally, if the class is root, or the superclass has an initializer 
>> that takes no arguments, I propose adding @auto_init annotation, which would 
>> generate a default initializer, similar to what is done for structs:
>> 
>> @auto_init
>> class User {
>>  var name: String
>>  var password: String
>> }
>> 
>> Normally, such class would be illegal since it would have no accessible 
>> initializers. The annotation could specify the access control as well: 
>> @auto_init(private), @auto_init(internal), @auto_init(public).
>> 
>> If the class isn't root, but inherits from an object that has an initializer 
>> that takes no arguments (e.g. NSObject), this would be allowed as well and 
>> the initializer with no arguments would be called on super.
>> 
>> Any thoughts on this? Sorry, if this has been already discussed.
>> 
>> Charlie
>> 
>> ___
>> 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] Proposal SE-0009 Reconsideration

[Krystof Vasa via swift-evolution]

> The problem can also be easily mitigated by having the IDE use a different 
> color to display a variable based on where it was defined (eclipse come to 
> mind as an example). This is something the brain naturally notices without 
> paying any conscious attention.

Tell that to the colorblind :)

> 
>> -- E
>> 
>> ___
>> 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] Should we rename "class" when referring to protocol conformance?

[Patrick Smith via swift-evolution]

I just want to highlight the Photoshop history example. I agree you’d want as 
much state and memory shared between steps in the history.

However, I see nothing wrong with having pointers to pixel buffer, and that 
affecting the ‘purity’ of the state. The way Photoshop’s history is 
implemented, is every image is broken up into tiles. Changes are recorded only 
within touched tiles. 
(http://www.photoshopforphotographers.com/CC_2013/Help_guide/tp/History_palette.html
 
)
 This improves memory usage compared to a single pixel buffer. With a graphics 
programming workflow, say where a background thread or the GPU is involved, the 
contents of those pixel buffers are going to change independently to the 
history stack. I think there would no problem for the history steps to have 
pointers to their mutable pixel buffers. Once the thread/GPU has finished 
processing changes within a step’s pixel buffer, it is ‘sealed’ say with a 
flag, and can’t be mutated later.

The only other way I could think of is for each history step to use UUIDs to 
reference tile pixel buffers, and manage a separate map of [UUID: PixelBuffer]. 
Possibly this approach might have other benefits, but I think it doesn’t differ 
practically in ‘purity’ of state vs one state tree involving pointers. The 
purity is from the point of view of the programmer, where they know their 
system is purely additive.

The guarantee is in the system the programmer has created. Not allowing 
pointers to carefully managed mutable state is too rigid.


> On 23 May 2016, at 5:12 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On May 22, 2016, at 12:04 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Mon May 16 2016, Matthew Johnson > > wrote:
>> 
 On May 15, 2016, at 2:01 PM, Dave Abrahams
 > wrote:
 
 
 on Fri May 13 2016, Matthew Johnson >>> 
 >> 
 wrote:
 
>>> 
> Sent from my iPad
> 
>> On May 13, 2016, at 9:12 AM, Dave Abrahams > > wrote:
>> 
>> 
>>> on Mon May 09 2016, Matthew Johnson >> > wrote:
>>> 
>>> My claim is that substituting the constraint of “it has value
>>> semantics,” while presumably looser than the PureValue constraint, would
>>> not compromise the correctness of your view controller, so not only is
>>> the meaning of PureValue hard to define, but it doesn't buy you
>>> anything.  If you want to refute that, just show me the code.
>>> 
>>> This is not an algorithmic use but is still perfectly valid IMO.
>>> 
>>> If the properties of PureValue matter to your view controller, there's
>>> an algorithm somewhere that depends on those properties for its
>>> correctness.
>>> 
>>> In many cases it may just be view configuration that depends on those
>>> properties.  I suppose you can call view configuration code an
>>> algorithm but I think that would fall outside of common usage.
>> It's an algorithm, or if the configuration is declarative, there's
>> an algorithm that manipulates it.  That said, I still don't have a
>> concrete example of how view configuration can depend on these
>> properties.
> The algorithm might just be "copy x bit of data to y view
> property, etc".  That is so trivial that it feels like a stretch to
> call it an algorithm.
 
 Algorithms can be trivial.
>>> 
>>> Fair enough.  Although in most contexts people don’t use the word when
>>> discussing the trivial.
>> 
>> Yes, quite a shame, that.
>> 
> That "algorithm" doesn't depend on this property because it
> executes at a single point in time.  However, a view controller
> might depend on that property in order to render properly across
> time (for example, configuring cells as they scroll on and off
> screen).
 The example is too abstract for me to understand.
 
 Let me put this differently: I recognize that your concept of
 “PureValue” may be a *sufficient* condition for some generic
 algorithm/component to work, but it is never a *necessary*
 condition, because genericity (or use of a superclass or protocol
 type) erases details of the actual types involved from the point of
 view of the algorithm/component.  It doesn't matter if your type
 contains a class reference if it has value semantic properties.  My
 claim is that PureValue is an overly-restrictive constraint that
 makes many things less useful than they should be.
>>> 
>>> In many cases 

Re: [swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng via swift-evolution]

> 
> I think that *all* methods should be available - at least in principle - with 
> associated types 
> - replaced by their upper bounds (i.e. Any if no constraints have been given 
> either by the protocol definition itself or th existential) if in covariant 
> position and 
> - replaced by their lower bounds if in contravariant position
> 
> As it is not possible to define lower bounds in Swift, the lower bounds are 
> always the bottom type (called `Nothing` in Swift and not be confused with 
> optionals). The bottom type has no members and therefore a method referencing 
> that type cannot be called and is effectively not available.
> 

Thanks for the feedback! So methods that have associated types in contravariant 
position would have those types be Nothing, unless there was a concrete type 
bound to that associated type in the Any's where clause?

Example

protocol MyProtocol {
  associatedtype AssocType1
  associatedtype AssocType2
  func foo(x: AssocType1, y: AssocType2)
}

let a : Any
// on 'a', foo is exposed as 'foo(x: Nothing, y: Nothing)', and can thus not be 
called

let b : Any
// on 'b', foo is exposed as 'foo(x: Int, y: Nothing)' and still can't be called

let c : Any
// on 'c', foo is exposed as 'foo(x: Int, y: String)', and can therefore be 
called

Let me know if this is what you had in mind.

Austin

> -Thorsten 

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

Re: [swift-evolution] Enhanced existential types proposal discussion

[Thorsten Seitz via swift-evolution]

> Am 23.05.2016 um 00:18 schrieb Austin Zheng via swift-evolution 
> :
> 
> I agree; the difference between protocols with and without associated types 
> has been an endless source of confusion for a lot of people.
> 
> Speaking of which, for those who care I rewrote the draft proposal to attempt 
> a much more rigorous treatment of the semantics of the generalized 
> existential, including a discussion about existential type equivalence and 
> subtyping. It would be nice to see people poke holes in my logic so I can 
> patch them up. 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md

I think that *all* methods should be available - at least in principle - with 
associated types 
- replaced by their upper bounds (i.e. Any if no constraints have been given 
either by the protocol definition itself or th existential) if in covariant 
position and 
- replaced by their lower bounds if in contravariant position

As it is not possible to define lower bounds in Swift, the lower bounds are 
always the bottom type (called `Nothing` in Swift and not be confused with 
optionals). The bottom type has no members and therefore a method referencing 
that type cannot be called and is effectively not available.

-Thorsten 

> 
> Austin
> 
>>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> I agree with this. If we're certain we should reskin protocol<> as Any<>, 
>>> we should frontload that change—in addition to affecting source code, it'd 
>>> also influence the runtime behavior of type printing/parsing, which can't 
>>> be statically migrated in the future. I think any discussion of extending 
>>> existentials has to be considered out of scope for Swift 3, though, so the 
>>> Any rename deserves its own proposal.
>>> 
>>> -Joe
>> 
>> 
>> Its really unfortunate that the generics work is probably going to be 
>> deferred. When you really dive in to protocol-oriented programming and 
>> designing frameworks to be native Swift (taking advantage of Swift features) 
>> the existential problem comes up a lot and leads to sub-optimal designs, 
>> abandonment of type safety, or gobs of boilerplate.  
>> 
>> 
>> Russ
>> 
>> ___
>> 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] Proposal: Automatic initializer generation

[Kevin Nattinger via swift-evolution]

Discussed last month 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014890.html
And (linked from that thread) last year 
http://article.gmane.org/gmane.comp.lang.swift.evolution/727

I think it’s a good idea, but discussion seems to have just petered out without 
a formal proposal both times. 

How about we just apply the struct auto-init behavior to classes? It’s nice and 
simple, and already in the language.

> On May 23, 2016, at 7:29 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> A lot of initializers tediously assign values to variables which results in a 
> lot of code such as self.variable = arg1 (or even worse variable = variable), 
> mostly for classes that are meant to just encapsulate several values.
> 
> I propose adding auto keyword (to be discussed - anyone has a better name in 
> mind?), which would automatically assign same-named variables. Example:
> 
> class User {
>   var name: String
>   var password: String
>   
>   init(auto name: String, auto password: String) {
>   // No assignment required, the variables will be automatically 
> assigned.
>   // Perform additional init stuff here.
>   }
> }
> 
> This would, of course, work only if the argument has the same name as a 
> stored variable on the class.
> 
> Additionally, if the class is root, or the superclass has an initializer that 
> takes no arguments, I propose adding @auto_init annotation, which would 
> generate a default initializer, similar to what is done for structs:
> 
> @auto_init
> class User {
>   var name: String
>   var password: String
> }
> 
> Normally, such class would be illegal since it would have no accessible 
> initializers. The annotation could specify the access control as well: 
> @auto_init(private), @auto_init(internal), @auto_init(public).
> 
> If the class isn't root, but inherits from an object that has an initializer 
> that takes no arguments (e.g. NSObject), this would be allowed as well and 
> the initializer with no arguments would be called on super.
> 
> Any thoughts on this? Sorry, if this has been already discussed.
> 
> Charlie
> 
> ___
> 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] Static Dispatch Pitfalls

[Xiaodi Wu via swift-evolution]

On Mon, May 23, 2016 at 6:58 AM, Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On May 22, 2016, at 11:55 PM, Xiaodi Wu  wrote:
>
> On Sun, May 22, 2016 at 11:20 PM, Matthew Johnson 
> wrote:
>
>>
>> On May 22, 2016, at 4:22 PM, Xiaodi Wu  wrote:
>>
>> On Sun, May 22, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> > The proposal is well thought out and makes a valiant attempt at
>>> handling all of the issues necessary.  But I don't support it for a number
>>> of reasons.  I think it highlights how awkward it would be to try to
>>> address shadowing on a case-by-case basis, which isn't necessarily obvious
>>> until you explore what a solution might look like.
>>>
>>> It does, but I'm just not sure what else you can do about it. If there's
>>> a warning, you need a way to silence it. If you ignore some cases (like
>>> creating a conflict by importing two modules), you'll miss some of the
>>> subtlest and hardest-to-fix bugs.
>>>
>>> Honestly, I'm tempted to say "you just can't ever shadow a final
>>> protocol method" and be done with it. If that prevents certain conformances
>>> or stops certain imports, so be it. You can always work around that with
>>> wrapper types or other techniques.
>>>
>>
>> You know, I think this might be cleverest solution. It adds a small limit
>> to the language, but it doesn't unduly penalize retroactive modeling. If
>> you control either the protocol or the conforming type, you can change the
>> name of one of the methods so it doesn't shadow/get shadowed by the other.
>>
>>
>> If you control the conforming type this isn’t too big an issue as long as
>> the protocol was well designed.  However, if the protocol was poorly
>> designed it could be an issue.  Maybe a method that can be more efficiently
>> implemented by some types was not made a requirement, but an extension
>> method (with a slower implementation) takes the obvious name.  Maybe you
>> would be willing to live with the slower implementation when your type is
>> accessed via the protocol, because at least it can still be used via the
>> protocol, but you don’t want to burden callers who use the concrete type
>> with the slow implementation.  What do you do then?
>>
>
> If a method that really ought to be a protocol requirement isn't a
> requirement and you don't control the protocol, well you're pretty much out
> of luck even today. Any conforming type accessed via the protocol will use
> the less efficient extension method and nothing about Brent's proposal
> would make that worse or better.
>
> Shadowing of the slow extension method doesn't remove the burden. It may
> make calling your fast implementation look nicer, but a less informed user
> of your type would unwittingly call the slower implementation if they
> access your type via the protocol. You could instead:
> * come up with another name for your fast implementation; maybe the
> "obvious" name for the method is "frobnicate"--then name your method
> "quicklyFrobnicate";
>
> * or, decide you don't want to conform your type to a poorly designed
> protocol after all, instead retroactively modeling your type and other
> types of interest with a better designed protocol of your making.
>
>
> Maybe you want the type to inter operate with code you don't control and
> in order to do that it must conform to the protocol.  And you don't want to
> obfuscate the interface to the concrete type because the protocol is poorly
> designed.
>

I'm not sure this is a reasonable set of demands. I understand a protocol
to be a contract. If you decide to conform to a poorly designed protocol,
you *should* have a poorly designed concrete type. That is the purpose of a
protocol, to provide certain guarantees, be they wise or unwise. To me,
it's a bug rather than a feature to support papering over poor protocol
design when conforming to a protocol, which also forces the poor design to
be exposed only when accessing your type through that protocol. In the end,
you don't have a well-designed type; your type is instead simultaneously
well and poorly designed!


>  Conforming to the protocol *is not* the primary reason your type exists -
> conformance is used only for the purpose of using your type with a specific
> piece of third party code.
>
> You *could* wrap your type for the purpose of this conformance.  This is
> what a Brent alluded to.  But it requires boilerplate and a bunch of
> conversion operations.  This is not just annoying, it could also be complex
> enough to lead to bugs.
>
>
>
>> If you control the protocol but want to retroactively model types you do
>> not control this assumes you are willing to design your protocol around
>> those types.  What if one of those types happens to implement a method that
>> should not be a requirement of the protocol for one reason or another, but
>> will be implemented as an extension 

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

[Charlie Monroe via swift-evolution]

I've jotted up a proposal here:

https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385

Please let me know if there are any comments to it.

Charlie

> On May 20, 2016, at 9:11 AM, Krystof Vasa via swift-evolution 
>  wrote:
> 
>> Four questions:
>> 1. If I was printing a protocol type that Optional supports, such as Any, 
>> would I get a warning?
> 
> This was my bad, I wrote an incorrect example, 
> print("http://apple.com\(myURL.path) ") was 
> what I meant - which will print 
> 
> http://apple.comOptional(/iphone/) . 
> 
> Putting an optional directly into print(_:) should be fine with no warning. 
> Only within the string interpolation.
> 
>> 2. I believe debugDescription is discouraged from being called directly 
>> [from CustomDebugStringConvertible docs]. Perhaps String(reflecting: ) 
>> instead, although such debug description behavior could cause different 
>> results if you were expecting this fixit to apply to Any types.
> 
> This is not invoked on the value within the Optional, but directly *on* the 
> Optional. As declared here (part of Swift):
> 
> extension Optional : CustomDebugStringConvertible {
> /// A textual representation of `self`, suitable for debugging.
> public var debugDescription: String { get }
> }
> 
> Example:
> 
> let stringOptional: String? = "Hello"
> 
> // Notice no ? is used - the optional is not unwrapped
> stringOptional.debugDescription // Optional(Hello)
> 
> // Unwrapping the optional
> stringOptional!.debugDescription // Hello
> 
> Not sure what would be the impact of making Optional CustomStringConvertible 
> (i.e. instead of using debugDescription, one would use just description).
> 
>> 3. How would I have the ability to opt into this behavior for my own types 
>> (such as Result or Future)?
>> 4. How would I opt in/out of this behavior for my own 
>> StringInterpolationConvertible implementations?
> 
> This is not about customizing the interpolation but about warning the user 
> when using optionals in string interpolation to prevent from such mistakes as 
> above with the URL. This is more common than one would think and sometimes is 
> hard to spot. I'm sorry if I misunderstood you questions.
> 
>> 
>> -DW
>> 
>>> 
>>> I'm not saying *removing* the current behavior, but adding a warning for 
>>> this - you'd get the same result ignoring the warning and applying the 
>>> Fix-It, but you'd have control over this.
>>> 
 On May 20, 2016, at 6:48 AM, Dan Appel via swift-evolution 
 > wrote:
 
 >google for swift print optional stackoverflow. I think that kind of 
 >speaks for itself.
 
 I think this is actually an example of why the current behavior is a good 
 thing. I did just google that and the top comment of the first result 
 explains what an optional is. That is very good and encourages beginners 
 to understand how optionals work under the hood. If you hide that from 
 them, they will only be even more confused when they see just the string 
 "nil" pop up when it previously was showing the correct value.
 
 On Thu, May 19, 2016 at 9:36 PM Krystof Vasa via swift-evolution 
 > wrote:
 BTW - google for swift print optional stackoverflow. I think that kind of 
 speaks for itself.
 
 > On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution 
 > > wrote:
 >
 > -1
 >
 > This seems to me like crippling string interpolation just because 
 > sometimes we make mistakes. 99% of the time, if I interpolate an 
 > optional, it’s because I want it that way. I don’t want to have to put 
 > up with a warning or write the same boilerplate 99% of the time just to 
 > flag up the 1% more easily. Sorry.
 >
 >> On 18 May 2016, at 19:50, Krystof Vasa via swift-evolution 
 >> > wrote:
 >>
 >> The string interpolation is one of the strong sides of Swift, but also 
 >> one of its weaknesses.
 >>
 >> It has happened to me more than once that I've used the interpolation 
 >> with an optional by mistake and the result is then far from the 
 >> expected result.
 >>
 >> This happened mostly before Swift 2.0's guard expression, but has 
 >> happened since as well.
 >>
 >> The user will seldomly want to really get the output 
 >> "Optional(something)", but is almost always expecting just "something". 
 >> I believe this should be addressed by a warning to force the user to 
 >> check the expression to prevent unwanted results. If you indeed want 
 >> the output of an optional, it's almost always better to use the ?? 
 >> operator and 

[swift-evolution] Proposal: Automatic initializer generation

[Charlie Monroe via swift-evolution]

A lot of initializers tediously assign values to variables which results in a 
lot of code such as self.variable = arg1 (or even worse variable = variable), 
mostly for classes that are meant to just encapsulate several values.

I propose adding auto keyword (to be discussed - anyone has a better name in 
mind?), which would automatically assign same-named variables. Example:

class User {
var name: String
var password: String

init(auto name: String, auto password: String) {
// No assignment required, the variables will be automatically 
assigned.
// Perform additional init stuff here.
}
}

This would, of course, work only if the argument has the same name as a stored 
variable on the class.

Additionally, if the class is root, or the superclass has an initializer that 
takes no arguments, I propose adding @auto_init annotation, which would 
generate a default initializer, similar to what is done for structs:

@auto_init
class User {
var name: String
var password: String
}

Normally, such class would be illegal since it would have no accessible 
initializers. The annotation could specify the access control as well: 
@auto_init(private), @auto_init(internal), @auto_init(public).

If the class isn't root, but inherits from an object that has an initializer 
that takes no arguments (e.g. NSObject), this would be allowed as well and the 
initializer with no arguments would be called on super.

Any thoughts on this? Sorry, if this has been already discussed.

Charlie

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

Re: [swift-evolution] Initialiser Helper

[Patrick Smith via swift-evolution]

You could move getAge() to be a private func outside of the scope of Person?


> On 23 May 2016, at 11:24 PM, James Campbell via swift-evolution 
>  wrote:
> 
> I would like to be able to use functions to help me initilise a class or 
> struct so I can break down a init into seperate methods, like so:
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = json["age"]
> }
> 
> }
> 
> This can become un-wieldly, so I would love to be able to do this:
> 
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = getAge(json)
> }
> 
> private func getAge(json: Dictionary) -> Int {
> 
> }
> 
> }
> ___
> 
> James⎥
> 
> ja...@supmenow.com ⎥supmenow.com 
> 
> Sup
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> London
> 
> 
> EC2A 1AF 
> 
> ___
> 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] Initialiser Helper

[Matthew Johnson via swift-evolution]

You might be interested in taking a look at my proposal for partial 
initializers 
https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md

This proposal was tabled for Swift 3 but I hope to revisit the topic of 
improving initializers in when we ramp up Swift 4.

Sent from my iPad

> On May 23, 2016, at 8:24 AM, James Campbell via swift-evolution 
>  wrote:
> 
> I would like to be able to use functions to help me initilise a class or 
> struct so I can break down a init into seperate methods, like so:
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = json["age"]
> }
> 
> }
> 
> This can become un-wieldly, so I would love to be able to do this:
> 
> 
> struct Person {
> 
> let age: Int
> 
> init (json: Dictionary) {
> // lots of code
> 
> age = getAge(json)
> }
> 
> private func getAge(json: Dictionary) -> Int {
> 
> }
> 
> }
> ___
> 
> James⎥
> 
> ja...@supmenow.com⎥supmenow.com
> 
> Sup
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> London
> 
> 
> EC2A 1AF 
> 
> ___
> 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] Enhanced existential types proposal discussion

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 22, 2016, at 5:18 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> I agree; the difference between protocols with and without associated types 
> has been an endless source of confusion for a lot of people.
> 
> Speaking of which, for those who care I rewrote the draft proposal to attempt 
> a much more rigorous treatment of the semantics of the generalized 
> existential, including a discussion about existential type equivalence and 
> subtyping. It would be nice to see people poke holes in my logic so I can 
> patch them up. 
> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md

This looks really nice.  I really, really appreciate all of your hard work on 
this.  It addresses one of the very largest pain points in Swift and does so 
comprehensively.  (The other really large pain point IMO is lack of conditional 
conformance).

I haven't had time to thoroughly review every detail but didn't see errors in a 
relatively quick glance over it.

> 
> Austin
> 
>>> On May 22, 2016, at 3:05 PM, Russ Bishop via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On May 17, 2016, at 1:55 PM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> I agree with this. If we're certain we should reskin protocol<> as Any<>, 
>>> we should frontload that change—in addition to affecting source code, it'd 
>>> also influence the runtime behavior of type printing/parsing, which can't 
>>> be statically migrated in the future. I think any discussion of extending 
>>> existentials has to be considered out of scope for Swift 3, though, so the 
>>> Any rename deserves its own proposal.
>>> 
>>> -Joe
>> 
>> 
>> Its really unfortunate that the generics work is probably going to be 
>> deferred. When you really dive in to protocol-oriented programming and 
>> designing frameworks to be native Swift (taking advantage of Swift features) 
>> the existential problem comes up a lot and leads to sub-optimal designs, 
>> abandonment of type safety, or gobs of boilerplate.  
>> 
>> 
>> Russ
>> 
>> ___
>> 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] [Pitch] Add `mapValues` method to Dictionary

[Tim Vermeulen via swift-evolution]

I really like this idea, because indeed this wasn’t possible functionally 
before. I have a small remark though, wouldn’t it be better to let transform be 
of type (Key, Value) throws -> T instead of (Value) throws -> T? You can just 
ignore the key (with _) if you don’t need it, but I think it might come in 
handy in some cases.

> Hello everyone,
> 
> I have added a very simple, but powerful method into a Dictionary extension 
> on multiple projects in the last weeks, so I'd like to bring up the idea of 
> adding it into the standard library, in case other people can see its 
> benefits as well.
> 
> Currently, Dictionary conforms to Collection with its Element being the tuple 
> of Key and Value. Thus transforming the Dictionary with regular map results 
> in [T], whereas I'd find it more useful to also have a method which results 
> in [Key:T].
> 
> Let me present an example of where this makes sense.
> 
> I recently used the GitHub API to crawl some information about repositories. 
> I started with just names (e.g. "/apple/swift", "/apple/llvm") and fetched a 
> JSON response for each of the repos, each returning a dictionary, which got 
> saved into one large dictionary as the end of the full operation, keyed by 
> its name, so the structure was something like
> 
> {
> "/apple/swift": { "url":..., "size":, "homepage":... },
> "/apple/llvm": { "url":..., "size":, "homepage":... },
> ...
> }
> 
> To perform analysis, I just needed a dictionary mapping the name of the 
> repository to its size, freeing me to discard the rest of the results.
> This is where things get interesting, because you can't keep this action 
> nicely functional anymore. I had to do the following:
> 
> let repos: [String: JSON] = ...
> var sizes: [String: Int] = [:]
> for (key, value) in repos {
> sizes[key] = value["size"].int
> }
> // use sizes...
> 
> Which isn't a huge amount of work, but it creates unnecessary mutable state 
> in your transformation pipeline (and your current scope). And I had to write 
> it enough times to justify bringing it up on this list.
> 
> I suggest we add the following method to Dictionary:
> 
> extension Dictionary {
> public func mapValues(_ transform: @noescape (Value) throws ->T) rethrows 
> ->[Key: T] {
> var transformed: [Key: T] = [:]
> for (key, value) in self {
> transformed[key] = try transform(value)
> }
> return transformed
> }
> }
> 
> It is modeled after Collection's `map` function, with the difference that
> a) only values are transformed, instead of the Key,Value tuple and
> b) the returned structure is a transformed Dictionary [Key:T], instead of [T]
> 
> This now allows a much nicer workflow:
> 
> let repos: [String: JSON] = ...
> var sizes = repos.mapValues { $0["size"].int }
> // use sizes...
> 
> and even multi-step transformations on Dictionaries, previously only possible 
> on Arrays, e.g.
> var descriptionTextLengths = repos.mapValues { $0["description"].string 
> }.mapValues { $0.characters.count }
> 
> You get the idea.
> 
> What do you think? I welcome all feedback, I'd like to see if people would 
> support it before I write a proper proposal.
> 
> Thanks! :)
> Honza Dvorsky
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Static Dispatch Pitfalls

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 22, 2016, at 11:55 PM, Xiaodi Wu  wrote:
> 
>> On Sun, May 22, 2016 at 11:20 PM, Matthew Johnson  
>> wrote:
>> 
>>> On May 22, 2016, at 4:22 PM, Xiaodi Wu  wrote:
>>> 
 On Sun, May 22, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution 
  wrote:
 > The proposal is well thought out and makes a valiant attempt at handling 
 > all of the issues necessary.  But I don't support it for a number of 
 > reasons.  I think it highlights how awkward it would be to try to 
 > address shadowing on a case-by-case basis, which isn't necessarily 
 > obvious until you explore what a solution might look like.
 
 It does, but I'm just not sure what else you can do about it. If there's a 
 warning, you need a way to silence it. If you ignore some cases (like 
 creating a conflict by importing two modules), you'll miss some of the 
 subtlest and hardest-to-fix bugs.
 
 Honestly, I'm tempted to say "you just can't ever shadow a final protocol 
 method" and be done with it. If that prevents certain conformances or 
 stops certain imports, so be it. You can always work around that with 
 wrapper types or other techniques.
>>> 
>>> You know, I think this might be cleverest solution. It adds a small limit 
>>> to the language, but it doesn't unduly penalize retroactive modeling. If 
>>> you control either the protocol or the conforming type, you can change the 
>>> name of one of the methods so it doesn't shadow/get shadowed by the other.
>> 
>> If you control the conforming type this isn’t too big an issue as long as 
>> the protocol was well designed.  However, if the protocol was poorly 
>> designed it could be an issue.  Maybe a method that can be more efficiently 
>> implemented by some types was not made a requirement, but an extension 
>> method (with a slower implementation) takes the obvious name.  Maybe you 
>> would be willing to live with the slower implementation when your type is 
>> accessed via the protocol, because at least it can still be used via the 
>> protocol, but you don’t want to burden callers who use the concrete type 
>> with the slow implementation.  What do you do then?
> 
> If a method that really ought to be a protocol requirement isn't a 
> requirement and you don't control the protocol, well you're pretty much out 
> of luck even today. Any conforming type accessed via the protocol will use 
> the less efficient extension method and nothing about Brent's proposal would 
> make that worse or better.
> 
> Shadowing of the slow extension method doesn't remove the burden. It may make 
> calling your fast implementation look nicer, but a less informed user of your 
> type would unwittingly call the slower implementation if they access your 
> type via the protocol. You could instead:
> * come up with another name for your fast implementation; maybe the "obvious" 
> name for the method is "frobnicate"--then name your method 
> "quicklyFrobnicate";
> * or, decide you don't want to conform your type to a poorly designed 
> protocol after all, instead retroactively modeling your type and other types 
> of interest with a better designed protocol of your making.

Maybe you want the type to inter operate with code you don't control and in 
order to do that it must conform to the protocol.  And you don't want to 
obfuscate the interface to the concrete type because the protocol is poorly 
designed.  Conforming to the protocol *is not* the primary reason your type 
exists - conformance is used only for the purpose of using your type with a 
specific piece of third party code.

You *could* wrap your type for the purpose of this conformance.  This is what a 
Brent alluded to.  But it requires boilerplate and a bunch of conversion 
operations.  This is not just annoying, it could also be complex enough to lead 
to bugs.

>  
>> If you control the protocol but want to retroactively model types you do not 
>> control this assumes you are willing to design your protocol around those 
>> types.  What if one of those types happens to implement a method that should 
>> not be a requirement of the protocol for one reason or another, but will be 
>> implemented as an extension method.  What do you do then?
> 
> I'm not sure I quite understand when this arises. Surely, by construction, if 
> you wish to retroactively model types, you are willing to design your 
> protocol around them. What else could it mean to retroactively model existing 
> types? Can you give a concrete example where during retroactively modeling 
> you simply have no choice but to name an extension method using a name that 
> it is shadowed by a conforming type?

I'm not saying you have *no choice*.  But again, conforming the one problematic 
type is not the primary purpose for which you are designing the protocol.  You 
know the shadowing method will not 

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

[Charlie Monroe via swift-evolution]

The clean way would be to make it an enum with var signum that would return -1, 
0, 1:

enum IntegerSign {

case Negative
case Zero
case Positive

var signum: NumberType {
switch self {
case .Negative:
return -1 as NumberType
case .Zero:
return 0 as NumberType
case .Positive:
return 1 as NumberType
}
}

}

extension SignedNumberType {
var sign: IntegerSign {
if self == 0 {
return .Zero
} else if self > 0 {
return .Positive
} else {
return .Negative
}
}
}

Charlie

> On May 23, 2016, at 9:29 AM, Haravikk via swift-evolution 
>  wrote:
> 
> Could you give an example of this method’s usage? Surely your value is either 
> positive, negative or zero already, so this method doesn’t return anything 
> more useful.
> 
> In other words, anywhere that I might do this:
> 
>   if myValue.sign > 0 { … }
> 
> I could just as easily do:
> 
>   if myValue > 0 { … }
> 
> To the same end result surely? Unless I’m missing something it seems 
> redundant.
> 
> If there is a use-case for this, would it make more sense to have the return 
> type as an enum with cases for Positive, Negative and Zero?
> 
>> On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution 
>> > wrote:
>> 
>> Howdy,
>> I think that the SignedNumberType should implement a method called sign that 
>> will return -1 for negative numbers, 0 for 0 and 1 for positive numbers. 
>> This is similar to the signum method in e.g. Java and similarly called 
>> methods in other languages.
>> 
>> The implementation is fairly straight forward
>> 
>> extension SignedNumberType {
>>   var sign: Self {
>> if self == 0 {
>>   return 0
>> }
>> else if self > 0 {
>>   return 1
>> }
>> return -1
>>   }
>> } 
>> 
>> I was trying to implement is without branching by doing (x > 0) - (x < 0) 
>> but I couldn't get the types right so I'm open to suggestions.
>> 
>> 
>> ___
>> 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] Winding down the Swift 3 release

[Jeremy Pereira via swift-evolution]

> On 19 May 2016, at 10:47, Brent Royal-Gordon  wrote:
> 
>> Is completing the generic system fundamental or not? I’d say it is vastly 
>> more fundamental than removing C style for loops, wouldn’t you?
> 
> Oh, come on. Removing the C-style for loop is not what took up time in this 
> release cycle. What took up time is the API guidelines, the new collection 
> model, and other standard library quality work—things which, in hindsight, 
> are prerequisites for binary compatibility anyway, because linking against a 
> different version doesn't count for much when all the names and calls have 
> changed anyway.

It is one of many things that have been done instead of concentrating on the 
goals as originally stated, five of which will not be met.

The collection model, API guidelines and standard library are actually 
irrelevant to the ABI. The standard library API and the Swift ABI are distinct 
orthogonal concepts.


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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