Re: [swift-evolution] [pitch] make @nonobjc the default

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> Currently, if you extend a class that comes from obj-c, Swift assumes you 
> want to make those methods available to call from obj-c code. If you add 
> operators, you must declare them as @nonobjc otherwise the bridging header 
> which is generated declares obj-c methods with the operator character as the 
> method name, which isn't valid in obj-c and causes compile errors.

The operators bit is an outright bug, which I believe has already been fixed in 
master. 

> I'm just wondering how others feel about this - my feeling is that a Swift 
> developer should not have to know anything about obj-c when doing Swifty 
> things to a bridged class from a framework (such as extending it). As far as 
> they are concerned the framework class should compile the same as if it were 
> fully implemented in Swift.

Modulo bugs like the above, I think we already have this property? Swift 
declarations are exposed to Objective-C if they can be. One doesn't generally 
have to think about it unless you're trying to use those declarations from 
Objective-C. 

> Thoughts?

I actually thought you were going further with this, eliminating the inferred 
@objc except in cases where it's needed to work with an existing framework. 
That's something I'd love to see someone working on.

  - Doug

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

Re: [swift-evolution] Some clarity lost from the great renaming

[Charles Srstka via swift-evolution]

They can always add the new mapping, and leave the old one there but deprecate 
it.

Charles

> On Oct 18, 2016, at 8:51 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> Is changing the mapping of Cocoa API considered a source breaking change or 
> can we report such incidents as bugs if we think they don’t match API 
> guidelines?
> 
>> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>> 
>> on Tue Oct 18 2016, Brandon Knope > > wrote:
>> 
>>> I meant to bring this up a bit ago but just came across it again.
>>> 
>>> I find this to not read properly:
>>> 
>>> button.setTitle("Test", for: .normal) //for normal what?
>>> 
>>> The for argument is really only clear in meaning when you are typing
>>> it out and see that it is a UIControlState type. While reading it
>>> without this context is it as clear? .normal doesn't seem descriptive
>>> enough on its own.
>>> 
>>> Contrast this with UISegmentedControl:
>>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
>>> .normal, barMetrics:
>>> .default)
>>> 
>>> Here the parameter labels are needed because there needs to be a
>>> distinction in the method between left and right. But here it is not
>>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>>> 
>>> So my question is: why was this not setTitle(forControlState:) or 
>>> forButtonState, etc...?
>> 
>> This is really not an evolution question at this point.  I suggest
>> filing radars against UIKit for things whose names could be improved.
>> 
>> -- 
>> -Dave
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Some clarity lost from the great renaming

[Dennis Lysenko via swift-evolution]

Agree on this particular case being unintuitive. I've come across a number
of such cases in Swift 3 but never really put too much thought into them.
Maybe you could just use for: UIControlState.normal until a resolution for
this is found (if there is one).

On Tue, Oct 18, 2016 at 10:32 PM Dennis Lysenko 
wrote:

> I think if it's one example like in this instance then a compiler
> directive to specify mapping if one does not already exist would be a more
> prudent option than changing the entire mapping.
>
> On Tue, Oct 18, 2016 at 9:51 PM Hooman Mehr via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Is changing the mapping of Cocoa API considered a source breaking change
> or can we report such incidents as bugs if we think they don’t match API
> guidelines?
>
> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Tue Oct 18 2016, Brandon Knope  wrote:
>
> I meant to bring this up a bit ago but just came across it again.
>
> I find this to not read properly:
>
> button.setTitle("Test", for: .normal) //for normal what?
>
> The for argument is really only clear in meaning when you are typing
> it out and see that it is a UIControlState type. While reading it
> without this context is it as clear? .normal doesn't seem descriptive
> enough on its own.
>
> Contrast this with UISegmentedControl:
> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState:
> .normal, barMetrics:
> .default)
>
> Here the parameter labels are needed because there needs to be a
> distinction in the method between left and right. But here it is not
> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>
> So my question is: why was this not setTitle(forControlState:) or
> forButtonState, etc...?
>
>
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some clarity lost from the great renaming

[Dennis Lysenko via swift-evolution]

I think if it's one example like in this instance then a compiler directive
to specify mapping if one does not already exist would be a more prudent
option than changing the entire mapping.

On Tue, Oct 18, 2016 at 9:51 PM Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> Is changing the mapping of Cocoa API considered a source breaking change
> or can we report such incidents as bugs if we think they don’t match API
> guidelines?
>
> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> on Tue Oct 18 2016, Brandon Knope  wrote:
>
> I meant to bring this up a bit ago but just came across it again.
>
> I find this to not read properly:
>
> button.setTitle("Test", for: .normal) //for normal what?
>
> The for argument is really only clear in meaning when you are typing
> it out and see that it is a UIControlState type. While reading it
> without this context is it as clear? .normal doesn't seem descriptive
> enough on its own.
>
> Contrast this with UISegmentedControl:
> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState:
> .normal, barMetrics:
> .default)
>
> Here the parameter labels are needed because there needs to be a
> distinction in the method between left and right. But here it is not
> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>
> So my question is: why was this not setTitle(forControlState:) or
> forButtonState, etc...?
>
>
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some clarity lost from the great renaming

[Hooman Mehr via swift-evolution]

Is changing the mapping of Cocoa API considered a source breaking change or can 
we report such incidents as bugs if we think they don’t match API guidelines?

> On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Tue Oct 18 2016, Brandon Knope  > wrote:
> 
>> I meant to bring this up a bit ago but just came across it again.
>> 
>> I find this to not read properly:
>> 
>> button.setTitle("Test", for: .normal) //for normal what?
>> 
>> The for argument is really only clear in meaning when you are typing
>> it out and see that it is a UIControlState type. While reading it
>> without this context is it as clear? .normal doesn't seem descriptive
>> enough on its own.
>> 
>> Contrast this with UISegmentedControl:
>> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
>> .normal, barMetrics:
>> .default)
>> 
>> Here the parameter labels are needed because there needs to be a
>> distinction in the method between left and right. But here it is not
>> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>> 
>> So my question is: why was this not setTitle(forControlState:) or 
>> forButtonState, etc...?
> 
> This is really not an evolution question at this point.  I suggest
> filing radars against UIKit for things whose names could be improved.
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some clarity lost from the great renaming

[Dave Abrahams via swift-evolution]

on Tue Oct 18 2016, Brandon Knope  wrote:

> I meant to bring this up a bit ago but just came across it again.
>
> I find this to not read properly:
>
> button.setTitle("Test", for: .normal) //for normal what?
>
> The for argument is really only clear in meaning when you are typing
> it out and see that it is a UIControlState type. While reading it
> without this context is it as clear? .normal doesn't seem descriptive
> enough on its own.
>
> Contrast this with UISegmentedControl:
> segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
> .normal, barMetrics:
> .default)
>
> Here the parameter labels are needed because there needs to be a
> distinction in the method between left and right. But here it is not
> forLeft: or forRight: it is the much more clear forLeftSegmentState:
>
> So my question is: why was this not setTitle(forControlState:) or 
> forButtonState, etc...?

This is really not an evolution question at this point.  I suggest
filing radars against UIKit for things whose names could be improved.

-- 
-Dave

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

[swift-evolution] Some clarity lost from the great renaming

[Brandon Knope via swift-evolution]

I meant to bring this up a bit ago but just came across it again.

I find this to not read properly:

button.setTitle("Test", for: .normal) //for normal what?

The for argument is really only clear in meaning when you are typing it out and 
see that it is a UIControlState type. While reading it without this context is 
it as clear? .normal doesn't seem descriptive enough on its own.

Contrast this with UISegmentedControl:
segmented.dividerImage(forLeftSegmentState: .normal, rightSegmentState: 
.normal, barMetrics: .default)

Here the parameter labels are needed because there needs to be a distinction in 
the method between left and right. But here it is not forLeft: or forRight: it 
is the much more clear forLeftSegmentState:

So my question is: why was this not setTitle(forControlState:) or 
forButtonState, etc...?

Brandon
Sent from my iPad___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [pitch] make @nonobjc the default

[Jay Abbott via swift-evolution]

Currently, if you extend a class that comes from obj-c, Swift assumes you
want to make those methods available to call from obj-c code. If you add
operators, you must declare them as @nonobjc otherwise the bridging header
which is generated declares obj-c methods with the operator character as
the method name, which isn't valid in obj-c and causes compile errors.

I'm just wondering how others feel about this - my feeling is that a Swift
developer should not have to know anything about obj-c when doing Swifty
things to a bridged class from a framework (such as extending it). As far
as they are concerned the framework class should compile the same as if it
were fully implemented in Swift.

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

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

[Max Moiseev via swift-evolution]

Yes, if the author of the collection you’re using performs the check in 
`removeLast`, but they don’t have to.

> On Oct 18, 2016, at 1:28 PM, Jean-Daniel  wrote:
> 
> 
>> Le 17 oct. 2016 à 23:20, Max Moiseev via swift-evolution 
>>  a écrit :
>> 
>> Hi Louis,
>> 
>> I believe, sometimes there are situations where you know for sure that your 
>> collection is not empty. Maybe you are already in the context where the 
>> check has been performed. In these cases there is no reason you’d have to 
>> pay the price of an emptiness check once again.
> 
> You have to pay the price anyway, as the check has to be performed to decide 
> if the software should abort.
> 
> 

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Haravikk via swift-evolution]

Personally I prefer the way Optionals currently work (add one bit), but I think 
a better compromise would be the ability to specify arbitrary width integers.

For example, I have a type that stores an optional (so 1-bit overhead) and I 
want to store less than a byte of extra data; if I could specify a 7-bit 
integer then I could limit overhead to a single byte, but currently cannot (at 
least, not without using single Bools which I don't want to do.


For collections there may be other options; for example, storing the 
optionality of values in a separate bitmap, which would reduce memory overhead, 
perhaps types could be added that can do this? For storing lots of optionals 
this would be more efficient on memory, with a slight overhead for double 
optionality checking. Here's a quick example of what I mean:

struct OptionalArray : Collection {
var values:[T] = [], bitmap:[Bool] = [], defaultValue:T

init(defaultValue:T) { self.defaultValue = defaultValue }
init(_ theElements:S, defaultValue:T) where S.Iterator.Element 
== T? {
self.defaultValue = defaultValue

self.values.reserveCapacity(theElements.underestimatedCount)
self.bitmap.reserveCapacity(theElements.underestimatedCount)

for eachElement in theElements {
self.values.append(eachElement ?? defaultValue)
self.bitmap.append(eachElement != nil)
}
}

var count:Int { return self.values.count }

var startIndex:Int { return self.values.startIndex }
var endIndex:Int { return self.values.endIndex }

func formIndex(after i:inout Int) { self.values.formIndex(after: ) }
func index(after i:Int) -> Int { return self.values.index(after: i) }

subscript(index:Int) -> T? {
get { return self.bitmap[index] ? self.values[index] : nil }
set { self.values[index] = newValue ?? self.defaultValue }
}
}

You could easily adapt this to store optionality using a default value that's 
unlikely to occur, like so:

struct OptionalArrayAlt : Collection {
var values:[T] = [], defaultValue:T

init(defaultValue:T) { self.defaultValue = defaultValue }
init(_ theElements:S, defaultValue:T) where S.Iterator.Element 
== T? {
self.defaultValue = defaultValue
values.reserveCapacity(theElements.underestimatedCount)
self.values = theElements.map { return $0 ?? defaultValue }
}

var count:Int { return self.values.count }

var startIndex:Int { return self.values.startIndex }
var endIndex:Int { return self.values.endIndex }

func formIndex(after i:inout Int) { self.values.formIndex(after: ) }
func index(after i:Int) -> Int { return self.values.index(after: i) }

subscript(index:Int) -> T? {
get { let value = self.values[index]; return value == self.defaultValue 
? value : nil }
set { self.values[index] = newValue ?? self.defaultValue }
}
}

With the caveat that you either can't store values equal to defaultValue (they 
become nil) or add an assertion/error if that value is stored.

But yeah, I don't think that rolling out the idea to all optionals is a good 
idea; the biggest gains will be had in collections, so any efforts should be 
focused there IMO, and on making custom types align better if possible.
> On 18 Oct 2016, at 21:32, Jean-Daniel via swift-evolution 
>  wrote:
> 
> 
>> Le 18 oct. 2016 à 21:09, Charlie Monroe via swift-evolution 
>>  a écrit :
>> 
>> Talking about bridging - my guess is that it would mess with NSNotFound 
>> which still has legit use cases even in Swift (when dealing with ObjC APIs) 
>> and is defined as NSIntegerMax at this moment, though its usage is slowly on 
>> the decline…
> 
> Bridge the API that may return NSNotFound to return optional. It would work 
> perfectly well as the nil optional and NSNotFound would have the same binary 
> representation.
> 
> 
>> But there are still many many APIs (mostly C-based) that define some "magic" 
>> constants as (unsigned)(-1), which I believe this would mess with.
>> 
>> Given this, it would IMHO have huge consequences for backward compatiblity.
>> 
>>> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution 
>>>  wrote:
>>> 
>>> Part of the beauty of how optionals are implemented in Swift is that the 
>>> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
>>> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case 
>>> .some(x)`, auto-boxing when necessary, etc.). 
>>> - I strongly dislike the idea of special-casing optionals just to save a 
>>> Byte. 
>>> - Optionals were presented as explicitly removing the need for such a 
>>> sentinel value in the first place.
>>> - There are reasonable cases where such a bit pattern is reasonably 
>>> necessary to the data (e.g. bit fields, RSSI, IP addresses, etc.) and 
>>> removing that value would force ugly workarounds and/or moving to a larger 
>>> 

Re: [swift-evolution] [stdlib] Collection mutators availability inconsistent

[Dave Abrahams via swift-evolution]

on Tue Oct 18 2016, Max Moiseev  wrote:

> Hi Louis,
>
> I believe the difference is due to the performance guarantees. One can
> only efficiently implement `popFirst` and `removeFirst` on slices,
> where it’s just a matter of index manipulation. 

Well, and on deques, doubly-linked lists, and circular buffers.

> Removing the first element of a Collection is potentially an O(n)
> operation. Using `popFirst` in a loop in some algorithm would result
> in a quadratic complexity.
>
> So the reason is: we only provide `popFirst` in a context where it is
> guaranteed to be O(1). Same applies to `popLast`, actually.. I think.

Right.

--
Dave

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Jean-Daniel via swift-evolution]

> Le 18 oct. 2016 à 21:09, Charlie Monroe via swift-evolution 
>  a écrit :
> 
> Talking about bridging - my guess is that it would mess with NSNotFound which 
> still has legit use cases even in Swift (when dealing with ObjC APIs) and is 
> defined as NSIntegerMax at this moment, though its usage is slowly on the 
> decline…

Bridge the API that may return NSNotFound to return optional. It would work 
perfectly well as the nil optional and NSNotFound would have the same binary 
representation.


> But there are still many many APIs (mostly C-based) that define some "magic" 
> constants as (unsigned)(-1), which I believe this would mess with.
> 
> Given this, it would IMHO have huge consequences for backward compatiblity.
> 
>> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution 
>>  wrote:
>> 
>> Part of the beauty of how optionals are implemented in Swift is that the 
>> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
>> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case 
>> .some(x)`, auto-boxing when necessary, etc.). 
>> - I strongly dislike the idea of special-casing optionals just to save a 
>> Byte. 
>> - Optionals were presented as explicitly removing the need for such a 
>> sentinel value in the first place.
>> - There are reasonable cases where such a bit pattern is reasonably 
>> necessary to the data (e.g. bit fields, RSSI, IP addresses, etc.) and 
>> removing that value would force ugly workarounds and/or moving to a larger 
>> int size because of an ill-advised implementation detail.
>> - If performance or memory is so critical to your specific use case, use a 
>> non-optional and your own sentinel value. It’s likely no less efficient than 
>> having the compiler do it that way.
>> 
>> (more below)
>> 
>>> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>>>  wrote:
>>> 
>>> Currently, Swift Int family and UInt family have compact representations 
>>> that utilize all available values, which is inherited from C. However, it 
>>> is horribly inefficient to implement optional integers. It takes double the 
>>> space to store [Int?] than to store [Int] because of alignment.
>>> 
>>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>>> family would lose its smallest value, and UInt family would lose its 
>>> largest value. Top value is reserved for nil in optionals. An additional 
>>> benefit is that negating an Int would never crash.
>>> 
>>> Interacting with C/Obj-C is a major concern, but since we are already 
>>> importing some of the unsigned integers as Int which loses half the values,
>> 
>> I’d argue those imports are bugs and should be fixed to the correct 
>> signedness.
>> 
>>> one value is not such big a drawback.
>> 
>> Unless you happen to need all $width bits.
>> 
>>> Alternatively, we could leave current behavior as CInt/CUInt. Converting 
>>> them to the new Int?/UInt? doesn't generate any instructions since the 
>>> invalid value already represents nil.
>> 
>> Trying to convert an invalid value like that crashes in most of Swift.
>> 
>>> 
>>> With optional integers improved, we could implement safe arithmetic 
>>> efficiently, or even revisit lenient subscript proposals,
>> 
>> I don’t see how losing a particular value has any effect on either of those, 
>> but it’s possible there’s some theory or implementation detail I’m not aware 
>> of.
>> 
>>> but they are not in the scope of this pitch. Float/Double optionals could 
>>> also be improved with the similar idea. (Isn't signaling nan the same as 
>>> nil) Nested optionals such as "Int??" are still bloated, but I don't think 
>>> they are widely used.
>>> 
>>> So what do you think? Can we break C compatibility a bit for better Swift 
>>> types?
>> 
>> We can, and do. C.f. structs, non-@objc classes, and enums not 
>> RawRepresentable with a C-compatible entity. If anything, this breaks 
>> compatibility with the rest of Swift.
>> 
>>> 
>>> - Guoye
>>> ___
>>> 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] Why doesn't removeLast() on Collection return an optional?

[Jean-Daniel via swift-evolution]

> Le 17 oct. 2016 à 23:20, Max Moiseev via swift-evolution 
>  a écrit :
> 
> Hi Louis,
> 
> I believe, sometimes there are situations where you know for sure that your 
> collection is not empty. Maybe you are already in the context where the check 
> has been performed. In these cases there is no reason you’d have to pay the 
> price of an emptiness check once again.

You have to pay the price anyway, as the check has to be performed to decide if 
the software should abort.


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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

> 在 2016年10月18日，15:30，David Waite  写道：
> 
> 
>> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution 
>>  wrote:
>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>> family would lose its smallest value, and UInt family would lose its largest 
>> value. Top value is reserved for nil in optionals. An additional benefit is 
>> that negating an Int would never crash.
> 
> There are two ways to do this (using Int8 for example)
> 1. 0xFF reserved to mean nil. As this normally means -1, all negative numbers 
> now use complements rather than two’s complement form. This breaks a lot of 
> binary math.
> 
> 2. 0x80 reserved to mean nil. This is normally -128. Overflow would have to 
> be modified in order to support this (otherwise, 127 + 1 == nil). bit padding 
> no longer works (0x80 would expand to 0xFF80 for a Int16 with bit padding, 
> not 0x8000)

Yes, 0x80 is better for arithmetic, checking for nil might be slower.

> 
>> 
>> Interacting with C/Obj-C is a major concern, but since we are already 
>> importing some of the unsigned integers as Int which loses half the values, 
>> one value is not such big a drawback. Alternatively, we could leave current 
>> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
>> generate any instructions since the invalid value already represents nil.
>> 
> 
> As the appropriate integer minimum value may already be in use in C or 
> Objective C code, I believe you would need to define a new integer types to 
> support this sort of constrained type. 
> 
> Where I would see something like this be most appropriate would be for 
> supporting a “BigNumber” type in the language, preferably as the default 
> integer type. Ruby does this for example with Fixnum/Bignum - all values in 
> Ruby are actually tagged pointers (where the lower bits are set to cause 
> invalid alignment of a pointer in order to indicate it is a special case 
> immediate value). So if the lowest bit is set, the value is a FixNum integer 
> with a lower max/higher min than a traditional integer. On overflow, the 
> value is promoted to be a BigNum, which is a reference to an arbitrary sized 
> integer on the heap.
> 
> -DW

I would also like to see big number some day.

- Guoye

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[David Waite via swift-evolution]

> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution 
>  wrote:
> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
> family would lose its smallest value, and UInt family would lose its largest 
> value. Top value is reserved for nil in optionals. An additional benefit is 
> that negating an Int would never crash.

There are two ways to do this (using Int8 for example)
1. 0xFF reserved to mean nil. As this normally means -1, all negative numbers 
now use complements rather than two’s complement form. This breaks a lot of 
binary math.

2. 0x80 reserved to mean nil. This is normally -128. Overflow would have to be 
modified in order to support this (otherwise, 127 + 1 == nil). bit padding no 
longer works (0x80 would expand to 0xFF80 for a Int16 with bit padding, not 
0x8000)

> 
> Interacting with C/Obj-C is a major concern, but since we are already 
> importing some of the unsigned integers as Int which loses half the values, 
> one value is not such big a drawback. Alternatively, we could leave current 
> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
> generate any instructions since the invalid value already represents nil.
> 

As the appropriate integer minimum value may already be in use in C or 
Objective C code, I believe you would need to define a new integer types to 
support this sort of constrained type. 

Where I would see something like this be most appropriate would be for 
supporting a “BigNumber” type in the language, preferably as the default 
integer type. Ruby does this for example with Fixnum/Bignum - all values in 
Ruby are actually tagged pointers (where the lower bits are set to cause 
invalid alignment of a pointer in order to indicate it is a special case 
immediate value). So if the lowest bit is set, the value is a FixNum integer 
with a lower max/higher min than a traditional integer. On overflow, the value 
is promoted to be a BigNum, which is a reference to an arbitrary sized integer 
on the heap.

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Charlie Monroe via swift-evolution]

Which would required all developers to update all APIs to annotate, where some 
magic value may be used - because otherwise all non-Swift APIs would return 
optional Ints or run into risk of crashing during runtime (since once entering 
Swift code, the value would become nil)...

I agree that it would be the ideal case, but reastically, given how many APIs 
out there are still with no nullability annotations (and it's been what - 3-4 
years now?), I don't see this practical...

> On Oct 18, 2016, at 9:16 PM, Guoye Zhang  wrote:
> 
> In that case, NSNotFound can be seamlessly converted to nil. Those magic 
> might also be better represented in optionals. It is indeed bad for 
> compatibility otherwise.
> 
> - Guoye
> 
>> 在 2016年10月18日，15:09，Charlie Monroe  写道：
>> 
>> Talking about bridging - my guess is that it would mess with NSNotFound 
>> which still has legit use cases even in Swift (when dealing with ObjC APIs) 
>> and is defined as NSIntegerMax at this moment, though its usage is slowly on 
>> the decline...
>> 
>> But there are still many many APIs (mostly C-based) that define some "magic" 
>> constants as (unsigned)(-1), which I believe this would mess with.
>> 
>> Given this, it would IMHO have huge consequences for backward compatiblity.
>> 
>>> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution 
>>>  wrote:
>>> 
>>> Part of the beauty of how optionals are implemented in Swift is that the 
>>> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
>>> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case 
>>> .some(x)`, auto-boxing when necessary, etc.). 
>>> - I strongly dislike the idea of special-casing optionals just to save a 
>>> Byte. 
>>> - Optionals were presented as explicitly removing the need for such a 
>>> sentinel value in the first place.
>>> - There are reasonable cases where such a bit pattern is reasonably 
>>> necessary to the data (e.g. bit fields, RSSI, IP addresses, etc.) and 
>>> removing that value would force ugly workarounds and/or moving to a larger 
>>> int size because of an ill-advised implementation detail.
>>> - If performance or memory is so critical to your specific use case, use a 
>>> non-optional and your own sentinel value. It’s likely no less efficient 
>>> than having the compiler do it that way.
>>> 
>>> (more below)
>>> 
 On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
  wrote:
 
 Currently, Swift Int family and UInt family have compact representations 
 that utilize all available values, which is inherited from C. However, it 
 is horribly inefficient to implement optional integers. It takes double 
 the space to store [Int?] than to store [Int] because of alignment.
 
 I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
 family would lose its smallest value, and UInt family would lose its 
 largest value. Top value is reserved for nil in optionals. An additional 
 benefit is that negating an Int would never crash.
 
 Interacting with C/Obj-C is a major concern, but since we are already 
 importing some of the unsigned integers as Int which loses half the values,
>>> 
>>> I’d argue those imports are bugs and should be fixed to the correct 
>>> signedness.
>>> 
 one value is not such big a drawback.
>>> 
>>> Unless you happen to need all $width bits.
>>> 
 Alternatively, we could leave current behavior as CInt/CUInt. Converting 
 them to the new Int?/UInt? doesn't generate any instructions since the 
 invalid value already represents nil.
>>> 
>>> Trying to convert an invalid value like that crashes in most of Swift.
>>> 
 
 With optional integers improved, we could implement safe arithmetic 
 efficiently, or even revisit lenient subscript proposals,
>>> 
>>> I don’t see how losing a particular value has any effect on either of 
>>> those, but it’s possible there’s some theory or implementation detail I’m 
>>> not aware of.
>>> 
 but they are not in the scope of this pitch. Float/Double optionals could 
 also be improved with the similar idea. (Isn't signaling nan the same as 
 nil) Nested optionals such as "Int??" are still bloated, but I don't think 
 they are widely used.
 
 So what do you think? Can we break C compatibility a bit for better Swift 
 types?
>>> 
>>> We can, and do. C.f. structs, non-@objc classes, and enums not 
>>> RawRepresentable with a C-compatible entity. If anything, this breaks 
>>> compatibility with the rest of Swift.
>>> 
 
 - Guoye
 ___
 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] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

> 在 2016年10月18日，15:15，Joe Groff  写道：
> 
>> 
>> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>>  wrote:
>> 
>> Currently, Swift Int family and UInt family have compact representations 
>> that utilize all available values, which is inherited from C. However, it is 
>> horribly inefficient to implement optional integers. It takes double the 
>> space to store [Int?] than to store [Int] because of alignment.
>> 
>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>> family would lose its smallest value, and UInt family would lose its largest 
>> value. Top value is reserved for nil in optionals. An additional benefit is 
>> that negating an Int would never crash.
>> 
>> Interacting with C/Obj-C is a major concern, but since we are already 
>> importing some of the unsigned integers as Int which loses half the values, 
>> one value is not such big a drawback. Alternatively, we could leave current 
>> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
>> generate any instructions since the invalid value already represents nil.
>> 
>> With optional integers improved, we could implement safe arithmetic 
>> efficiently, or even revisit lenient subscript proposals, but they are not 
>> in the scope of this pitch. Float/Double optionals could also be improved 
>> with the similar idea. (Isn't signaling nan the same as nil) Nested 
>> optionals such as "Int??" are still bloated, but I don't think they are 
>> widely used.
>> 
>> So what do you think? Can we break C compatibility a bit for better Swift 
>> types?
> 
> I don't think we'd ever be able to do this for unsigned values, since their 
> use as bitmasks is pervasive and requires all inhabitants. There's some 
> appeal to taking the least negative value away from signed int types, since 
> as you noted, it would define away the potential for negation and division to 
> overflow. There would be several tradeoffs:
> 
> - It makes overflow checking more expensive. Most CPUs have hardware support 
> for detecting two's complement signed overflow, but checking for INT_MIN 
> would require additional code after every potentially-overflowing operation, 
> greatly increasing the code size and performance hit we'd pay for safe 
> arithmetic.
> - It would make Swift integer values not "toll-free bridge" with C integers, 
> complicating the interface between Swift and C APIs. We could import C APIs 
> to use Int? or Int!, but that would inflict pain on the client-side code that 
> has to check those optionals.
> 
> If someone was bringing up a CPU from the silicon up to run Swift code, to 
> run a software environment with little or no C interop, reserving INT_MIN 
> would definitely be an interesting design point to consider, but we decided 
> that it wasn't practical for Swift's target platforms today. There are other 
> things we can do to mitigate the size cost of Int? compared to Int. Although 
> we don't take full advantage of it today, Swift understands the layout of 
> types at the *bit* level, and we plan to optimize things so that structs 
> containing many bit-sized components, such as Bools or the out-of-line tags 
> for multiple Optionals, can be automatically packed into bitfields by 
> default. Note that `Int??` already has the same size as `Int?`, since Swift 
> knows it's already burned a tag bit to represent 'nil' and can just store 
> different numeric values in the payload with the tag bit set to distinguish 
> '.some(.none)' from '.none'. (It's true that the `Array` type is constrained 
> by presenting its elements as contiguous in memory and well-aligned, so 
> `[Int?]` will likely never be very efficiently represented, but you could 
> fairly easily represent a collection of optional Ints more efficiently 
> SoA-style by passing around a pair of [Int] and a bit vector, or else 
> reserving an Int value you know to be unused in your own domain and passing 
> around [Int].lazy.map { $0 == Int.min ? nil : $0 } or something similar.)
> 
> -Joe

Thanks for your response. I'm glad to know that it is discussed.

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

In that case, NSNotFound can be seamlessly converted to nil. Those magic might 
also be better represented in optionals. It is indeed bad for compatibility 
otherwise.

- Guoye

> 在 2016年10月18日，15:09，Charlie Monroe  写道：
> 
> Talking about bridging - my guess is that it would mess with NSNotFound which 
> still has legit use cases even in Swift (when dealing with ObjC APIs) and is 
> defined as NSIntegerMax at this moment, though its usage is slowly on the 
> decline...
> 
> But there are still many many APIs (mostly C-based) that define some "magic" 
> constants as (unsigned)(-1), which I believe this would mess with.
> 
> Given this, it would IMHO have huge consequences for backward compatiblity.
> 
>> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution 
>>  wrote:
>> 
>> Part of the beauty of how optionals are implemented in Swift is that the 
>> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
>> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case 
>> .some(x)`, auto-boxing when necessary, etc.). 
>> - I strongly dislike the idea of special-casing optionals just to save a 
>> Byte. 
>> - Optionals were presented as explicitly removing the need for such a 
>> sentinel value in the first place.
>> - There are reasonable cases where such a bit pattern is reasonably 
>> necessary to the data (e.g. bit fields, RSSI, IP addresses, etc.) and 
>> removing that value would force ugly workarounds and/or moving to a larger 
>> int size because of an ill-advised implementation detail.
>> - If performance or memory is so critical to your specific use case, use a 
>> non-optional and your own sentinel value. It’s likely no less efficient than 
>> having the compiler do it that way.
>> 
>> (more below)
>> 
>>> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>>>  wrote:
>>> 
>>> Currently, Swift Int family and UInt family have compact representations 
>>> that utilize all available values, which is inherited from C. However, it 
>>> is horribly inefficient to implement optional integers. It takes double the 
>>> space to store [Int?] than to store [Int] because of alignment.
>>> 
>>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>>> family would lose its smallest value, and UInt family would lose its 
>>> largest value. Top value is reserved for nil in optionals. An additional 
>>> benefit is that negating an Int would never crash.
>>> 
>>> Interacting with C/Obj-C is a major concern, but since we are already 
>>> importing some of the unsigned integers as Int which loses half the values,
>> 
>> I’d argue those imports are bugs and should be fixed to the correct 
>> signedness.
>> 
>>> one value is not such big a drawback.
>> 
>> Unless you happen to need all $width bits.
>> 
>>> Alternatively, we could leave current behavior as CInt/CUInt. Converting 
>>> them to the new Int?/UInt? doesn't generate any instructions since the 
>>> invalid value already represents nil.
>> 
>> Trying to convert an invalid value like that crashes in most of Swift.
>> 
>>> 
>>> With optional integers improved, we could implement safe arithmetic 
>>> efficiently, or even revisit lenient subscript proposals,
>> 
>> I don’t see how losing a particular value has any effect on either of those, 
>> but it’s possible there’s some theory or implementation detail I’m not aware 
>> of.
>> 
>>> but they are not in the scope of this pitch. Float/Double optionals could 
>>> also be improved with the similar idea. (Isn't signaling nan the same as 
>>> nil) Nested optionals such as "Int??" are still bloated, but I don't think 
>>> they are widely used.
>>> 
>>> So what do you think? Can we break C compatibility a bit for better Swift 
>>> types?
>> 
>> We can, and do. C.f. structs, non-@objc classes, and enums not 
>> RawRepresentable with a C-compatible entity. If anything, this breaks 
>> compatibility with the rest of Swift.
>> 
>>> 
>>> - Guoye
>>> ___
>>> 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] Ban the top value in Int/UInt

[Joe Groff via swift-evolution]

> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>  wrote:
> 
> Currently, Swift Int family and UInt family have compact representations that 
> utilize all available values, which is inherited from C. However, it is 
> horribly inefficient to implement optional integers. It takes double the 
> space to store [Int?] than to store [Int] because of alignment.
> 
> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
> family would lose its smallest value, and UInt family would lose its largest 
> value. Top value is reserved for nil in optionals. An additional benefit is 
> that negating an Int would never crash.
> 
> Interacting with C/Obj-C is a major concern, but since we are already 
> importing some of the unsigned integers as Int which loses half the values, 
> one value is not such big a drawback. Alternatively, we could leave current 
> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
> generate any instructions since the invalid value already represents nil.
> 
> With optional integers improved, we could implement safe arithmetic 
> efficiently, or even revisit lenient subscript proposals, but they are not in 
> the scope of this pitch. Float/Double optionals could also be improved with 
> the similar idea. (Isn't signaling nan the same as nil) Nested optionals such 
> as "Int??" are still bloated, but I don't think they are widely used.
> 
> So what do you think? Can we break C compatibility a bit for better Swift 
> types?

I don't think we'd ever be able to do this for unsigned values, since their use 
as bitmasks is pervasive and requires all inhabitants. There's some appeal to 
taking the least negative value away from signed int types, since as you noted, 
it would define away the potential for negation and division to overflow. There 
would be several tradeoffs:

- It makes overflow checking more expensive. Most CPUs have hardware support 
for detecting two's complement signed overflow, but checking for INT_MIN would 
require additional code after every potentially-overflowing operation, greatly 
increasing the code size and performance hit we'd pay for safe arithmetic.
- It would make Swift integer values not "toll-free bridge" with C integers, 
complicating the interface between Swift and C APIs. We could import C APIs to 
use Int? or Int!, but that would inflict pain on the client-side code that has 
to check those optionals.

If someone was bringing up a CPU from the silicon up to run Swift code, to run 
a software environment with little or no C interop, reserving INT_MIN would 
definitely be an interesting design point to consider, but we decided that it 
wasn't practical for Swift's target platforms today. There are other things we 
can do to mitigate the size cost of Int? compared to Int. Although we don't 
take full advantage of it today, Swift understands the layout of types at the 
*bit* level, and we plan to optimize things so that structs containing many 
bit-sized components, such as Bools or the out-of-line tags for multiple 
Optionals, can be automatically packed into bitfields by default. Note that 
`Int??` already has the same size as `Int?`, since Swift knows it's already 
burned a tag bit to represent 'nil' and can just store different numeric values 
in the payload with the tag bit set to distinguish '.some(.none)' from '.none'. 
(It's true that the `Array` type is constrained by presenting its elements as 
contiguous in memory and well-aligned, so `[Int?]` will likely never be very 
efficiently represented, but you could fairly easily represent a collection of 
optional Ints more efficiently SoA-style by passing around a pair of [Int] and 
a bit vector, or else reserving an Int value you know to be unused in your own 
domain and passing around [Int].lazy.map { $0 == Int.min ? nil : $0 } or 
something similar.)

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Benjamin Spratling via swift-evolution]

> On Oct 18, 2016, at 1:54 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> Part of the beauty of how optionals are implemented in Swift is that the 
> compiler doesn’t have to do any magic w.r.t. optionals 
> - I strongly dislike the idea of special-casing optionals just to save a 
> Byte. 
It is nice that enums are generic, but enums do know about extra bits laying 
around and compact themselves if possible.

As I understand it, It would actually save 7.875 bytes of storage.  When the 
next stored value is Int-alignment, 7 extra bytes beyond the optional marking 
are used up.  For code which uses several Int? in a row, it doubles the 
required memory - as I understand it.

>  If anything, this breaks compatibility with the rest of Swift.
Yep.  So if it’s gonna be done, now's the time to do it.

An alternative is to introduce 63-bit and 31-bit integer types just to play 
nice with optionals.  Or to play nice with more than 2 enum cases, why not 
introduce 56- and 24-bit Int/UInt? and leave space for many cases.  Of course, 
there’s an added performance penalty when working with the mask, right?  Maybe 
opting in to these odd byte sizes lets the developer know that.

When working with Int / UInt the developer is not usually specifying “Int64”, 
but instead saying "big integer, oh, 64-bits, that should handle it.”  When 
they say “it might be 32-bits, uh oh”, then they explicitly specify Int64.  So 
maybe "typealias Int = Int56" solves this problem.

There was talk of adding a variable-byte-sized Integers to the built-ins in the 
future.  Maybe these changes could work together with that?

-Ben

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

Perhaps not considering the current instruction set. Safe arithmetics that 
produce optionals would be simpler though.

- Guoye

> 在 2016年10月18日，14:43，Nevin Brackett-Rozinsky 
>  写道：
> 
> If we went that route, could arithmetic operations still be implemented 
> efficiently?
> 
> Nevin
> 
> On Tuesday, October 18, 2016, Guoye Zhang via swift-evolution 
>  wrote:
> Currently, Swift Int family and UInt family have compact representations that 
> utilize all available values, which is inherited from C. However, it is 
> horribly inefficient to implement optional integers. It takes double the 
> space to store [Int?] than to store [Int] because of alignment.
> 
> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
> family would lose its smallest value, and UInt family would lose its largest 
> value. Top value is reserved for nil in optionals. An additional benefit is 
> that negating an Int would never crash.
> 
> Interacting with C/Obj-C is a major concern, but since we are already 
> importing some of the unsigned integers as Int which loses half the values, 
> one value is not such big a drawback. Alternatively, we could leave current 
> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't 
> generate any instructions since the invalid value already represents nil.
> 
> With optional integers improved, we could implement safe arithmetic 
> efficiently, or even revisit lenient subscript proposals, but they are not in 
> the scope of this pitch. Float/Double optionals could also be improved with 
> the similar idea. (Isn't signaling nan the same as nil) Nested optionals such 
> as "Int??" are still bloated, but I don't think they are widely used.
> 
> So what do you think? Can we break C compatibility a bit for better Swift 
> types?
> 
> - Guoye
> ___
> 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] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

> 在 2016年10月18日，14:54，Kevin Nattinger  写道：
> 
> Part of the beauty of how optionals are implemented in Swift is that the 
> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case .some(x)`, 
> auto-boxing when necessary, etc.). 
Swift compiler is already using magic for optional pointers. Invalid address 
are used for optional pointers. `MemoryLayout???>.size` is still 8.

> - I strongly dislike the idea of special-casing optionals just to save a 
> Byte. 
Not just a byte, it saves half the space in arrays. [Int?] is double the size 
of [Int].

> - Optionals were presented as explicitly removing the need for such a 
> sentinel value in the first place.
> - There are reasonable cases where such a bit pattern is reasonably necessary 
> to the data (e.g. bit fields, RSSI, IP addresses, etc.) and removing that 
> value would force ugly workarounds and/or moving to a larger int size because 
> of an ill-advised implementation detail.
I agree. Perhaps we just special case Int, and keep UInt intact for bitwise 
operations?

> - If performance or memory is so critical to your specific use case, use a 
> non-optional and your own sentinel value. It’s likely no less efficient than 
> having the compiler do it that way.
> 
> (more below)
> 
>> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>>  wrote:
>> 
>> Currently, Swift Int family and UInt family have compact representations 
>> that utilize all available values, which is inherited from C. However, it is 
>> horribly inefficient to implement optional integers. It takes double the 
>> space to store [Int?] than to store [Int] because of alignment.
>> 
>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>> family would lose its smallest value, and UInt family would lose its largest 
>> value. Top value is reserved for nil in optionals. An additional benefit is 
>> that negating an Int would never crash.
>> 
>> Interacting with C/Obj-C is a major concern, but since we are already 
>> importing some of the unsigned integers as Int which loses half the values,
> 
> I’d argue those imports are bugs and should be fixed to the correct 
> signedness.

It is for indexing Swift array easier.
> 
>> one value is not such big a drawback.
> 
> Unless you happen to need all $width bits.
> 
>> Alternatively, we could leave current behavior as CInt/CUInt. Converting 
>> them to the new Int?/UInt? doesn't generate any instructions since the 
>> invalid value already represents nil.
> 
> Trying to convert an invalid value like that crashes in most of Swift.

CInt to Optional would not crash because invalid value becomes nil.
> 
>> 
>> With optional integers improved, we could implement safe arithmetic 
>> efficiently, or even revisit lenient subscript proposals,
> 
> I don’t see how losing a particular value has any effect on either of those, 
> but it’s possible there’s some theory or implementation detail I’m not aware 
> of.

Unaligned memory access would be a huge performance hit.
> 
>> but they are not in the scope of this pitch. Float/Double optionals could 
>> also be improved with the similar idea. (Isn't signaling nan the same as 
>> nil) Nested optionals such as "Int??" are still bloated, but I don't think 
>> they are widely used.
>> 
>> So what do you think? Can we break C compatibility a bit for better Swift 
>> types?
> 
> We can, and do. C.f. structs, non-@objc classes, and enums not 
> RawRepresentable with a C-compatible entity. If anything, this breaks 
> compatibility with the rest of Swift.

I don't want that, either.
> 
>> 
>> - Guoye
>> ___
>> 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] Ban the top value in Int/UInt

[Charlie Monroe via swift-evolution]

Talking about bridging - my guess is that it would mess with NSNotFound which 
still has legit use cases even in Swift (when dealing with ObjC APIs) and is 
defined as NSIntegerMax at this moment, though its usage is slowly on the 
decline...

But there are still many many APIs (mostly C-based) that define some "magic" 
constants as (unsigned)(-1), which I believe this would mess with.

Given this, it would IMHO have huge consequences for backward compatiblity.

> On Oct 18, 2016, at 8:54 PM, Kevin Nattinger via swift-evolution 
>  wrote:
> 
> Part of the beauty of how optionals are implemented in Swift is that the 
> compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
> syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case .some(x)`, 
> auto-boxing when necessary, etc.). 
> - I strongly dislike the idea of special-casing optionals just to save a 
> Byte. 
> - Optionals were presented as explicitly removing the need for such a 
> sentinel value in the first place.
> - There are reasonable cases where such a bit pattern is reasonably necessary 
> to the data (e.g. bit fields, RSSI, IP addresses, etc.) and removing that 
> value would force ugly workarounds and/or moving to a larger int size because 
> of an ill-advised implementation detail.
> - If performance or memory is so critical to your specific use case, use a 
> non-optional and your own sentinel value. It’s likely no less efficient than 
> having the compiler do it that way.
> 
> (more below)
> 
>> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>>  wrote:
>> 
>> Currently, Swift Int family and UInt family have compact representations 
>> that utilize all available values, which is inherited from C. However, it is 
>> horribly inefficient to implement optional integers. It takes double the 
>> space to store [Int?] than to store [Int] because of alignment.
>> 
>> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
>> family would lose its smallest value, and UInt family would lose its largest 
>> value. Top value is reserved for nil in optionals. An additional benefit is 
>> that negating an Int would never crash.
>> 
>> Interacting with C/Obj-C is a major concern, but since we are already 
>> importing some of the unsigned integers as Int which loses half the values,
> 
> I’d argue those imports are bugs and should be fixed to the correct 
> signedness.
> 
>> one value is not such big a drawback.
> 
> Unless you happen to need all $width bits.
> 
>> Alternatively, we could leave current behavior as CInt/CUInt. Converting 
>> them to the new Int?/UInt? doesn't generate any instructions since the 
>> invalid value already represents nil.
> 
> Trying to convert an invalid value like that crashes in most of Swift.
> 
>> 
>> With optional integers improved, we could implement safe arithmetic 
>> efficiently, or even revisit lenient subscript proposals,
> 
> I don’t see how losing a particular value has any effect on either of those, 
> but it’s possible there’s some theory or implementation detail I’m not aware 
> of.
> 
>> but they are not in the scope of this pitch. Float/Double optionals could 
>> also be improved with the similar idea. (Isn't signaling nan the same as 
>> nil) Nested optionals such as "Int??" are still bloated, but I don't think 
>> they are widely used.
>> 
>> So what do you think? Can we break C compatibility a bit for better Swift 
>> types?
> 
> We can, and do. C.f. structs, non-@objc classes, and enums not 
> RawRepresentable with a C-compatible entity. If anything, this breaks 
> compatibility with the rest of Swift.
> 
>> 
>> - Guoye
>> ___
>> 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] Ban the top value in Int/UInt

[Kevin Nattinger via swift-evolution]

Part of the beauty of how optionals are implemented in Swift is that the 
compiler doesn’t have to do any magic w.r.t. optionals besides a bit of 
syntactic sugar (`T?` -> `Optional`, `if let x` -> `if let case .some(x)`, 
auto-boxing when necessary, etc.). 
- I strongly dislike the idea of special-casing optionals just to save a Byte. 
- Optionals were presented as explicitly removing the need for such a sentinel 
value in the first place.
- There are reasonable cases where such a bit pattern is reasonably necessary 
to the data (e.g. bit fields, RSSI, IP addresses, etc.) and removing that value 
would force ugly workarounds and/or moving to a larger int size because of an 
ill-advised implementation detail.
- If performance or memory is so critical to your specific use case, use a 
non-optional and your own sentinel value. It’s likely no less efficient than 
having the compiler do it that way.

(more below)

> On Oct 18, 2016, at 11:17 AM, Guoye Zhang via swift-evolution 
>  wrote:
> 
> Currently, Swift Int family and UInt family have compact representations that 
> utilize all available values, which is inherited from C. However, it is 
> horribly inefficient to implement optional integers. It takes double the 
> space to store [Int?] than to store [Int] because of alignment.
> 
> I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
> family would lose its smallest value, and UInt family would lose its largest 
> value. Top value is reserved for nil in optionals. An additional benefit is 
> that negating an Int would never crash.
> 
> Interacting with C/Obj-C is a major concern, but since we are already 
> importing some of the unsigned integers as Int which loses half the values,

I’d argue those imports are bugs and should be fixed to the correct signedness.

> one value is not such big a drawback.

Unless you happen to need all $width bits.

> Alternatively, we could leave current behavior as CInt/CUInt. Converting them 
> to the new Int?/UInt? doesn't generate any instructions since the invalid 
> value already represents nil.

Trying to convert an invalid value like that crashes in most of Swift.

> 
> With optional integers improved, we could implement safe arithmetic 
> efficiently, or even revisit lenient subscript proposals,

I don’t see how losing a particular value has any effect on either of those, 
but it’s possible there’s some theory or implementation detail I’m not aware of.

> but they are not in the scope of this pitch. Float/Double optionals could 
> also be improved with the similar idea. (Isn't signaling nan the same as nil) 
> Nested optionals such as "Int??" are still bloated, but I don't think they 
> are widely used.
> 
> So what do you think? Can we break C compatibility a bit for better Swift 
> types?

We can, and do. C.f. structs, non-@objc classes, and enums not RawRepresentable 
with a C-compatible entity. If anything, this breaks compatibility with the 
rest of Swift.

> 
> - Guoye
> ___
> 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] Ban the top value in Int/UInt

[Nevin Brackett-Rozinsky via swift-evolution]

If we went that route, could arithmetic operations still be implemented
efficiently?

Nevin

On Tuesday, October 18, 2016, Guoye Zhang via swift-evolution <
swift-evolution@swift.org> wrote:

> Currently, Swift Int family and UInt family have compact representations
> that utilize all available values, which is inherited from C. However, it
> is horribly inefficient to implement optional integers. It takes double the
> space to store [Int?] than to store [Int] because of alignment.
>
> I propose to ban the top value in Int/UInt which is 0x... in hex. Int
> family would lose its smallest value, and UInt family would lose its
> largest value. Top value is reserved for nil in optionals. An additional
> benefit is that negating an Int would never crash.
>
> Interacting with C/Obj-C is a major concern, but since we are already
> importing some of the unsigned integers as Int which loses half the values,
> one value is not such big a drawback. Alternatively, we could leave current
> behavior as CInt/CUInt. Converting them to the new Int?/UInt? doesn't
> generate any instructions since the invalid value already represents nil.
>
> With optional integers improved, we could implement safe arithmetic
> efficiently, or even revisit lenient subscript proposals, but they are not
> in the scope of this pitch. Float/Double optionals could also be improved
> with the similar idea. (Isn't signaling nan the same as nil) Nested
> optionals such as "Int??" are still bloated, but I don't think they are
> widely used.
>
> So what do you think? Can we break C compatibility a bit for better Swift
> types?
>
> - Guoye
> ___
> 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] Ban the top value in Int/UInt

[Guoye Zhang via swift-evolution]

Currently, Swift Int family and UInt family have compact representations that 
utilize all available values, which is inherited from C. However, it is 
horribly inefficient to implement optional integers. It takes double the space 
to store [Int?] than to store [Int] because of alignment.

I propose to ban the top value in Int/UInt which is 0x... in hex. Int 
family would lose its smallest value, and UInt family would lose its largest 
value. Top value is reserved for nil in optionals. An additional benefit is 
that negating an Int would never crash.

Interacting with C/Obj-C is a major concern, but since we are already importing 
some of the unsigned integers as Int which loses half the values, one value is 
not such big a drawback. Alternatively, we could leave current behavior as 
CInt/CUInt. Converting them to the new Int?/UInt? doesn't generate any 
instructions since the invalid value already represents nil.

With optional integers improved, we could implement safe arithmetic 
efficiently, or even revisit lenient subscript proposals, but they are not in 
the scope of this pitch. Float/Double optionals could also be improved with the 
similar idea. (Isn't signaling nan the same as nil) Nested optionals such as 
"Int??" are still bloated, but I don't think they are widely used.

So what do you think? Can we break C compatibility a bit for better Swift types?

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

[swift-evolution] [stdlib] Collection mutators availability inconsistent

[Louis D'hauwe via swift-evolution]

Collections have mutating functions for removing the first and last element.
One of these is popLast(), which will safely check if the collection is empty 
before popping the last element.

So calling popLast() is like doing:
if !collection.isEmpty {
collection.removeLast()
}

There also exists a popFirst() function, but what I find inconsistent is that 
popFirst() is only available on ArraySlice.

Example:
var collection = [1, 2, 3, 4]
collection.removeFirst() // works fine
collection.removeLast() // works fine
let last = collection.popLast() // works fine
let first = collection.popFirst() // Compile error: [Int] is not convertible to 
'ArraySlice'

Is it intended that popLast() is available on collections, but popFirst() is 
not?

– Louis D'hauwe___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Nevin Brackett-Rozinsky via swift-evolution]

It seems natural to me that currency symbols should be operators. This
would allow, for example, prefix and postfix operators that take a number
and return a “Currency” instance:

let inMyPocket = $20
let lochNess = £3.50
let twoBits = 25¢

if (inMyPocket - lochNess) > twoBits { … }

Of course, the unnamed closure parameter identifiers would conflict with
that use of the dollar sign. However, I think Anton has the right idea. We
already use the number sign for compiler magic, so it would make sense to
call the closure parameters #0, #1, etc. In my view those even read better
than what we have now.

Nevin


On Tue, Oct 18, 2016 at 12:19 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Mon Oct 17 2016, Jean-Denis Muys  wrote:
>
> > While I already tersely supported this proposal, following all the
> negative
> > reactions, I feel compelled to revisit my position. The main reason is
> that
> > it strikes me that most points of view so far, including mine, were
> really
> > culturally short sighted, and far too much US-centric.
> >
> > I totally agree that '$' being use by one (or even several) piece of code
> > is not reason enough to change the language. But I also think that it
> being
> > used by only one piece of code is no reason to reject the change.
> >
> > Most of us, including me, have been blinded by two things:
> >
> > 1- the use of the $ sign in other programming languages
> > 2- the use of the $ sign in Swift as a prefix for implicitly declared
> > closure parameters
> >
> > I think this second use is not Swifty at all. It clearly (to me) would
> fail
> > the litmus test "if it wasn't there, would you add it to the language?".
> Of
> > course, it has been blessed by time, and it has *become* Swifty, by usage
> > because it's a useful feature, despite the choice of its syntax being so
> > ugly (to my non-american eyes).
>
> I don't think it's un-swifty by any measure.  It's not particularly
> beautiful, I agree, but what would make a better, extremely terse, way
> to refer to a posiitional parameter of a closure?  Unless we can think
> of something that's obviously better, then it is thoroughly swifty: a
> pragmatic solution for an important problem.  Unless we can think
> of something that's obviously better, then it certainly *is* what we
> would have added to the language.
>
> > Similarly, I believe the use of the $ in other language should not be a
> > guide in the decision here, either positively, nor negatively. We may pay
> > some mild attention to the concern that we should perhaps avoid some
> > confusion. I haven't seen much of that.
> >
> > Now for the elephant in the room: '$' is a currency symbol. As such it
> > should be handled like any other currency symbol. Thinking otherwise
> would
> > be very culturally offensive.
>
> 
>
> >
> > In conclusion, I believe this proposal must be accepted, and actually
> > expanded to include ¥, ¢, £, and also to make it explicit that currency
> > symbols can be used in variable names as first and only character, as
> first
> > of many characters, and at any position.
> >
> > This would make $0, $1, $2… legal variable names. I believe this is OK.
> >
> > What would happen to implicitly declared closure parameters then?
> Nothing.
> > They would continue to be implicitly declared in the context of closures
> > that do not declare their parameters explicitly, similarly to `self`
> being
> > implicitly declared in the context of a class. A user willing to use $0
> > there would be facing a name collision, which is OK.
> >
> > Note that such a change is purely additive: no legal source code today
> > would fail with this change.
>
> That is actually a relatively un-swifty answer in some ways.  It means
> there are magic identifiers that are usable in all contexts but given
> special meaning in some contexts.  I think making the lexical roles of
> various currency symbols more consistent is a worthy goal, but I'm not
> sure this is the way to do it.
>
> > I hope that at the very least, I opened a new perspective on this
> proposal,
> > and I hope we can find a way to be less culturally biased.
>
> If there's cultural bias here, it's a bias based on programming language
> precedent. \$[0-9] has a long history of use as a positional parameter
> identifier in programming languages.  Swift very explicitly embraces
> *that* sort of “cultural bias.”  The culture of programmers matters.
>
> --
> -Dave
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Tony Allevato via swift-evolution]

On Fri, Oct 14, 2016 at 1:00 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier"
> begins now and runs through October 18. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.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?
>

-1. Since the dollar sign is used as a prefix for unnamed closure
arguments, allowing it to be used by itself as a user-defined identifier
would be odd and potentially confusing. It's also, IMO, a useless
standalone identifier because it provides zero self-documentation as to its
purpose. Reserving "$" means that users will know that when they see it, it
refers to something special and intrinsic to the language.


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

No. The library using it is using an undocumented and accidental "feature"
that was removed for sound reasons and the language shouldn't change to
support that.


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

No. The library that is motivating the change is trying to shoehorn
Javascript patterns into Swift; the language shouldn't be designed around
it. The author's own Cent library, which uses extensions, is a much more
Swift-appropriate way to tackle what the problem he's trying to solve.


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

Java and Javascript allow $ as a standalone identifier. I don't see a
reason to follow that in Swift, though.


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

Read the proposal.


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

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Dave Abrahams via swift-evolution]

on Mon Oct 17 2016, Jean-Denis Muys  wrote:

> While I already tersely supported this proposal, following all the negative
> reactions, I feel compelled to revisit my position. The main reason is that
> it strikes me that most points of view so far, including mine, were really
> culturally short sighted, and far too much US-centric.
>
> I totally agree that '$' being use by one (or even several) piece of code
> is not reason enough to change the language. But I also think that it being
> used by only one piece of code is no reason to reject the change.
>
> Most of us, including me, have been blinded by two things:
>
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared
> closure parameters
>
> I think this second use is not Swifty at all. It clearly (to me) would fail
> the litmus test "if it wasn't there, would you add it to the language?". Of
> course, it has been blessed by time, and it has *become* Swifty, by usage
> because it's a useful feature, despite the choice of its syntax being so
> ugly (to my non-american eyes).

I don't think it's un-swifty by any measure.  It's not particularly
beautiful, I agree, but what would make a better, extremely terse, way
to refer to a posiitional parameter of a closure?  Unless we can think
of something that's obviously better, then it is thoroughly swifty: a
pragmatic solution for an important problem.  Unless we can think
of something that's obviously better, then it certainly *is* what we
would have added to the language.

> Similarly, I believe the use of the $ in other language should not be a
> guide in the decision here, either positively, nor negatively. We may pay
> some mild attention to the concern that we should perhaps avoid some
> confusion. I haven't seen much of that.
>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.



>
> In conclusion, I believe this proposal must be accepted, and actually
> expanded to include ¥, ¢, £, and also to make it explicit that currency
> symbols can be used in variable names as first and only character, as first
> of many characters, and at any position.
>
> This would make $0, $1, $2… legal variable names. I believe this is OK.
>
> What would happen to implicitly declared closure parameters then? Nothing.
> They would continue to be implicitly declared in the context of closures
> that do not declare their parameters explicitly, similarly to `self` being
> implicitly declared in the context of a class. A user willing to use $0
> there would be facing a name collision, which is OK.
>
> Note that such a change is purely additive: no legal source code today
> would fail with this change.

That is actually a relatively un-swifty answer in some ways.  It means
there are magic identifiers that are usable in all contexts but given
special meaning in some contexts.  I think making the lexical roles of
various currency symbols more consistent is a worthy goal, but I'm not
sure this is the way to do it.

> I hope that at the very least, I opened a new perspective on this proposal,
> and I hope we can find a way to be less culturally biased.

If there's cultural bias here, it's a bias based on programming language
precedent. \$[0-9] has a long history of use as a positional parameter
identifier in programming languages.  Swift very explicitly embraces
*that* sort of “cultural bias.”  The culture of programmers matters.

-- 
-Dave

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

[swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[rintaro ishizaki via swift-evolution]

   * What is your evaluation of the proposal?

+1
We should do the best to avoid source breaking change in Swift4.
https://github.com/ankurp/Dollar is used in so many projects.
I believe removing this might discourage them from using Swift.

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

Yes

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

No. Also, I personally dislike symbol only identifier.
But IMO, we have to compromise this.

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

Quick reading.


2016-10-15 4:59 GMT+09:00 Chris Lattner via swift-evolution <
swift-evolution@swift.org>:

> Hello Swift community,
>
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier"
> begins now and runs through October 18. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposa
> ls/0144-allow-single-dollar-sign-as-valid-identifier.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,
>
> -Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jay Abbott via swift-evolution]

>
> Now for the elephant in the room: '$' is a currency symbol. As such it
> should be handled like any other currency symbol. Thinking otherwise would
> be very culturally offensive.
>

The fact that it's a currency symbol is totally irrelevant.
It's s symbol. Here are some others:
! & * ( . -

You wouldn't want to allow an identifier to start with any of those
symbols, for obvious reasons.

Programming languages need to reserve some characters and words for special
meanings. In this case: Yes $0, $1, etc. was probably influenced from other
languages; yes $ was probably used in those languages because it was a
convenient available character in the ASCII set, and therefore easy to type
on standard US and other English keyboards (where those languages were
developed and primarily used). This is simple history/legacy, and nothing
to do with the fact it is a currency symbol or any other reason that might
cause offense to anyone.

Unfortunately I think you have misunderstood this proposal. It is to allow
$ as a single-character identifier, even though it is reserved and not
allowed as an identifier-head.

If you think $ should be allowed as the first character of any identifier
(including the single $), then that would be a different proposal which
should cover all the other effects properly.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift Reflection

[Robert Goodman via swift-evolution]

 
I know that there has been some discussion around improving reflection in Swift and I wanted to add to the discussion with some of the work I have been trying to do using the Swift Language. I have been investigating using Swift to create a framework that provides a programming API to process data and execute functions in parallel on a cluster. The framework needs to be able instantiate these functions on the cluster workers and have the data processed by the functions. The plans are to use one of the existing cluster managers, such as Spark or Storm. As of today, I have been looking at using Spark. There would be a predefined set of functions supported such as map, fliter, join, etc. as defined by the cluster manager.
In my experimenting, I have run into a number of issues which I haven't been able to solve due to the limited support for reflection in Swift. In my description of the issues, I'm going to use APIs based on Spark since that is the cluster manager I have been playing with.
 
Parameter and Return types
 
The following is an example of a Swift class that maps to the RDD class in Spark.
 
public class RDD  {   public func collect() throws -> [T] {      }}
 
The value of T could be any basic type to a class. Even if the types are limited to basic types and known Spark types, the list of possibilities is large. From one of the Spark examples, T would be
 
  Tuple2>
 
The possible combinations of types is too large to be hard coded given Spark supports Tuples with 22 different types. I can get the type of T in a string, but haven't found a way to instantiate the type using the string. Is there some way around this problem?
User-Defined Functions
 
A programmer would define functions that will be executed on a cluster to process data. The programmer doesn't need to do special packaging of functions that run on a cluster. The programmer would code a filter function against the cluster the same way as the filter function for a Swift array. For instance, for a filter method such as the following:
 
let result = RDD.filter({ (value) -> Bool in    return value > 15})
 
The framework would need to be able to do reflection on the function to get the information needed to instantiate and call the function on the cluster workers. Following is some of the information needed:
     
  Module name  Class/Struct name  Function name  Parameter names and type information    Once on the cluster the framework would need to do the following:
 
  1. Instantiate the parameters. Again, a parameter could be a basic type to a class.  2. Dynamically load/import the module containing the function.  3. Find the function in the module that matches the signature.  4. Call the function.  5. Handle the return type.
 
With the existing Swift support for reflection, I couldn't get all of the information that is needed and what information I could get wasn't in a very convenient form. In some cases, I needed to parse a string to get the different parameter types. Even if I had the information, I didn't see a way to use the information to load the module and execute the function. My plans are to require the programmer to pass the location of modules and dependencies that need to be deployed to the cluster workers on application startup. Given the limitations of reflections in Swift, I don't see how this framework could be implemented. Since this needs to run on Linux, I want to avoid any solution that uses Objective C.
 
    Thanks
  BobRobert Goodman

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

Re: [swift-evolution] [Discussion] API Guidelines

[Charlie Monroe via swift-evolution]

Thanks, Dave and Tony, it really helped.



> On Oct 16, 2016, at 9:55 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> on Fri Oct 14 2016, Adrian Zubarev  > wrote:
> 
>> I’m still not convinced in some cases.
>> 
>> Take a look at UIViews and its method addSubview.
>> 
>> open func addSubview(_ view: UIView)
>> Personally I’d change or write this function like so:
>> 
>> open func add(subview: UIView)
>> This reduces unnecessary noise _ view for both the implementation and usage.
> 
> No, the usage is either v1.addSubview(v2) or v1.add(subview: v2) Neither
> usage introduces an underscore.  To a first approximation, how the
> implementation looks is irrelevant.  APIs are used many more times than
> they are written or looked up.
> 
> The word "subview" is part of the base name for at least two reasons:
> 
> 1. The primary reason is that the base name should capture the method's
>   core semantics, and adding a subview is semantically completely
>   different from, say, adding a gesture recognizer.  They become parts
>   of different logical collections on the view and come with utterly
>   different side-effects.
> 
> 2. It's important to have consistent and simple naming rules that work
>   well for most APIs, and any rule we could think of that would lead us
>   to breaking "add" from "subview" would either
> 
>   a) cause many APIs to become inarguably worse or
>   b) neccessitate complicating the naming rules to avoid damaging those
>  other APIs.
> 
>> // Implementation
>> open func add(subview: UIView) {
>>// `subview` is descriptive and just fine here
>> }
>> 
>> // Usage
>> 
>> self.view.add(subview: someOtherView)
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 14. Oktober 2016 um 16:42:06, Zach Waldowski via swift-evolution
>> (swift-evolution@swift.org) schrieb:
>> 
>> The base name of the function describes its core purpose.
>> 
>> There is no ambiguity instructing an Array to "append" something, but
>> there is context needed: "what are we appending? The contents of the
>> newElements parameter." But there is ambiguity asking URL to "give me a
>> new URL by appending". Appending what? Similarly, telling a collection
>> to "replace". Replace what?
>> 
>> A rule of thumb my team has applied is to put the parameter parens where
>> you would have put `with` in ObjC. This is instructive for your
>> questions as well. "URLByAppendingWithPathComponent" and
>> "replaceWithSubrange" wouldn't make sense, but "appendWithContentsOf"
>> does.
>> 
>> Cheers!
>>   Zachary Waldowski
>>   z...@waldowski.me
>> 
>> On Thu, Oct 13, 2016, at 10:30 PM, Charlie Monroe via swift-evolution
>> wrote:
>>> Hi there,
>>> 
>>> I am really grateful for the API guidelines that were created as part of
>>> Swift 3, however, I'm having trouble with distinguishing which part of
>>> the method name should be already an argument. To illustrate this, here
>>> are two examples:
>>> 
>>> // On Array
>>> public mutating func append(contentsOf newElements: S)
>>> 
>>> // On Foundation.URL
>>> public func appendingPathComponent(_ pathComponent: String) -> URL
>>> 
>>> 
>>> Is there a particular reason why it's not
>>> 
>>> public func appending(pathComponent: String) -> URL
>>> 
>>> ?
>>> 
>>> In my opinion the entire stdlib and Foundation is full of such
>>> discrepancies which make it hard to decide when you name your own methods
>>> since there are preceding cases in the language itself (or Foundation)
>>> that go both ways.
>>> 
>>> The same goes for why don't the replace methods (this is on String)
>>> follow the same - when there is append(contentsOf:):
>>> 
>>> public mutating func replaceSubrange(_ bounds: ClosedRange,
>>> with newElements: String)
>>> 
>>> instead of
>>> 
>>> public mutating func replace(subrange bounds: ClosedRange,
>>> with newElements: String)
>>> 
>>> 
>>> 
>>> I know there was an extensive discussion about this here when the stdlib
>>> names were discussed. And given that these would be breaking changes, I
>>> don't necessarily want to start a lengthy discussion about renaming those
>>> again - I'm just wondering what are the reasons behind this and what
>>> should be the correct naming conventions.
>>> 
>>> Thanks!
>>> 
>>> 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
>> 
> 
> -- 
> -Dave
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Jean-Denis Muys via swift-evolution]

I don't agree with the line of reasoning that goes something like that:

"Event though you have , I want to forbid every one
from using additive feature X because I don't like it, given "

I also don't understand why this would impede qualified import syntax. What
is wrong with:

import func Framework.someMethod, func OtherFramework.someOtherMethod

So far for me this is +1.

Because additive, not in scope for phase 1 of Swift 4, though, as most of
the topics on this list recently.

On 18 October 2016 at 08:01, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > I'd almost always prefer to have another three lines of a
> protocolvisible, than three lines of imports.
>
> Maybe you just need an editor that can fold the imports (e.g. JetBrains)
> ___
> 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-0144: Allow Single Dollar Sign as a Valid Identifier

[Anton Zhilin via swift-evolution]

I'd prefer to replace $ with # in closure parameters, plus make $ equal in
rights to other currency symbols.
In C and JS, dollar sign is actually equal in rights to other currency symbols.
Swift is closer to them than to Perl, Shell, PHP, so it makes sense to
follow them here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Import Conditionals

[Benjamin Spratling via swift-evolution]

Howdy,

There is already an accepted but not implemented proposal to determine whether 
a module can be imported and conditionally compile accordingly.
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

While the accepted change is certainly not as compact as your notation, it has 
the advantage that it supports more functionality.  I could, for example, 
include code in a file for UIKit, Cocoa, WatchKit and ostensibly some Linux UI 
framework depending on my target platform.  If my functionality is intended 
around adding a single consistent feature to a Type in each module, then this 
is how I want to organize my code.

Besides, “||” is so JavaScript.  In Swift it would be “??”, and it would 
potentially need to chain because there are more than 2 supported platforms.

Finally, I don’t see how you handle failure to import a module.  Does compile 
fail, or do you provide your own implementation of the desired functionality?  
When Apple adds a module on one platform but not on another, then I might need 
to write my own implementation for platforms on which it is missing, but depend 
on system integrated performance on the platforms they provide it for.  
“canimport” provides for either using other existing # patterns, but your 
proposal does not.

So I recommend checking out the already-accepted proposal.  But if you still 
need the syntax to get smaller, at least move to “??” so it looks like Swift 
instead of some other language.

-Ben


> On Oct 17, 2016, at 5:05 PM, Sean Alling via swift-evolution 
>  wrote:
> 
> Description
> 
> In an effort to both (1) reduce boilerplate code, and (2) promote 
> cross-platform reusability I propose that we implement the following Import 
> Conditional Operators: 
> 
> `||` and `&&`
> 
> Currently, import conditionals must be implemented like so:
> 
> ```
> #if os(Linux) || os(FreeBSD)
>   import Glibc
> #else
>   import Darwin
> #endif
> ```
> 
> With import conditional operators this would be condensed to:
> 
> ```
> import Glibc || Darwin
> ```
> 
> The first library/framework (Glibc) would be imported if found and the the 
> second (Darwin) only in the event the first should fail.
> 
> Other Caveats:
> 
> (A) —  we could limit this to one conditional operator per import line OR we 
> could implement order of operations. Obviously, there are tradeoffs of both 
> that we should discuss.
> 
> (B) — if-conditional statements currently explicitly show the import 
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this 
> new feature. I would argue that the reduction of boilerplate code would in 
> itself be worth this abstraction.
> 
> 
> --
> Sean Alling
> 
> ___
> 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-0144: Allow Single Dollar Sign as a Valid Identifier

[Rien via swift-evolution]

“culturally offensive” is not a logical argument.
A programming language should be logically consistent no matter how many 
cultures are offended by it.
If Swift is driven by SJW’s then very quickly it will cease to be an effective 
language.

Having said that, I cannot think of a logical reason not to allow the $ as a 
variable name.
I also cannot think of a good reason to use a single character variable name. 
Let alone a symbol. Let even further alone a symbol that is used in many other 
languages for a specific purpose.

So while Swift may allow the $ sign for logical consistency, using it as a 
variable name would disqualify the programmer imo.

Rien.

> On 18 Oct 2016, at 08:25, Jean-Denis Muys via swift-evolution 
>  wrote:
> 
> While I already tersely supported this proposal, following all the negative 
> reactions, I feel compelled to revisit my position. The main reason is that 
> it strikes me that most points of view so far, including mine, were really 
> culturally short sighted, and far too much US-centric.
> 
> I totally agree that '$' being use by one (or even several) piece of code is 
> not reason enough to change the language. But I also think that it being used 
> by only one piece of code is no reason to reject the change.
> 
> Most of us, including me, have been blinded by two things:
> 
> 1- the use of the $ sign in other programming languages
> 2- the use of the $ sign in Swift as a prefix for implicitly declared closure 
> parameters
> 
> I think this second use is not Swifty at all. It clearly (to me) would fail 
> the litmus test "if it wasn't there, would you add it to the language?". Of 
> course, it has been blessed by time, and it has *become* Swifty, by usage 
> because it's a useful feature, despite the choice of its syntax being so ugly 
> (to my non-american eyes).
> 
> Similarly, I believe the use of the $ in other language should not be a guide 
> in the decision here, either positively, nor negatively. We may pay some mild 
> attention to the concern that we should perhaps avoid some confusion. I 
> haven't seen much of that.
> 
> Now for the elephant in the room: '$' is a currency symbol. As such it should 
> be handled like any other currency symbol. Thinking otherwise would be very 
> culturally offensive.
> 
> So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
> Can I use any currency symbol as an variable name in Swift? According to 
> Xcode 8.1B3, not quite, but almost all of them.
> 
> According to Mac OS "Emoji and Symbols" browser, there are 37 currency 
> symbols in Unicode:
> 
> let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
> I tried every one of them as a variable name. All were accepted, except 3: ¥, 
> ¢, £:
> 
> // let ¥ = 1 // error: expected pattern
> 
> Note the poor error message.
> 
> Here are 33 successful attempts:
> 
> let $ = 1
> let € = 1
> let ₽ = 1
> let ₨ = 1
> let ₩ = 1
> let ฿ = 1
> let ₺ = 1
> let ₮ = 1
> let ₱ = 1
> let ₭ = 1
> let ₴ = 1
> let ₦ = 1
> let ৲ = 1
> let ৳ = 1
> let ૱ = 1
> let ௹ = 1
> let ₹ = 1
> let ₲ = 1
> let ₪ = 1
> let ₡ = 1
> let ₫ = 1
> let ៛ = 1
> let ₵ = 1
> let ₢ = 1
> let ₸ = 1
> let ₤ = 1
> let ₳ = 1
> let ₥ = 1
> let ₠ = 1
> let ₣ = 1
> let ₰ = 1
> let ₧ = 1
> let ₯ = 1
> let ₶ = 1
> 
> print("₶ = \(₶)")
> print(₶+₶+₶)
> 
> And finally, there is the very weird Rial Sign: ﷼
> It is ok to use it as an variable name too (again, according to Xcode8.1B3).
> But when trying to use it, Xcode switches to right-to-left mode, which makes 
> for strange (for my occidental eyes) behaviour and display. All the following 
> is OK in Xcode:
> 
> // unusual Xcode right-to-left behavior with Rial Sign
> let ﷼ = 21
> 
> print("﷼= \(﷼)") // will print ﷼= 21
> 
> Of course, this is just a data point, and Xcode8.1B3 should not be the 
> arbiter here. But I believe whether Swift accepts currency symbols as 
> variable names should be consistent. Either it accepts all of them, or it 
> includes all of them.
> 
> I see no reason to exclude them. On the contrary, it was a design feature of 
> Swift to relieve use from the shackles of the ASCII character set.
> 
> In conclusion, I believe this proposal must be accepted, and actually 
> expanded to include ¥, ¢, £, and also to make it explicit that currency 
> symbols can be used in variable names as first and only character, as first 
> of many characters, and at any position.
> 
> This would make $0, $1, $2… legal variable names. I believe this is OK.
> 
> What would happen to implicitly declared closure parameters then? Nothing. 
> They would continue to be implicitly declared in the context of closures that 
> do not declare their parameters explicitly, similarly to `self` being 
> implicitly declared in the context of a class. A user willing to use $0 there 
> would be facing a name collision, which is OK. 
> 
> Note that such a change is purely additive: no legal source code today would 
> fail with this 

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

[Jean-Denis Muys via swift-evolution]

While I already tersely supported this proposal, following all the negative
reactions, I feel compelled to revisit my position. The main reason is that
it strikes me that most points of view so far, including mine, were really
culturally short sighted, and far too much US-centric.

I totally agree that '$' being use by one (or even several) piece of code
is not reason enough to change the language. But I also think that it being
used by only one piece of code is no reason to reject the change.

Most of us, including me, have been blinded by two things:

1- the use of the $ sign in other programming languages
2- the use of the $ sign in Swift as a prefix for implicitly declared
closure parameters

I think this second use is not Swifty at all. It clearly (to me) would fail
the litmus test "if it wasn't there, would you add it to the language?". Of
course, it has been blessed by time, and it has *become* Swifty, by usage
because it's a useful feature, despite the choice of its syntax being so
ugly (to my non-american eyes).

Similarly, I believe the use of the $ in other language should not be a
guide in the decision here, either positively, nor negatively. We may pay
some mild attention to the concern that we should perhaps avoid some
confusion. I haven't seen much of that.

Now for the elephant in the room: '$' is a currency symbol. As such it
should be handled like any other currency symbol. Thinking otherwise would
be very culturally offensive.

So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
Can I use any currency symbol as an variable name in Swift? According to
Xcode 8.1B3, not quite, but almost all of them.

According to Mac OS "Emoji and Symbols" browser, there are 37 currency
symbols in Unicode:

let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
I tried every one of them as a variable name. All were accepted, except 3:
¥, ¢, £:

// let ¥ = 1 // error: expected pattern

Note the poor error message.

Here are 33 successful attempts:

let $ = 1

let € = 1

let ₽ = 1

let ₨ = 1

let ₩ = 1

let ฿ = 1

let ₺ = 1

let ₮ = 1

let ₱ = 1

let ₭ = 1

let ₴ = 1

let ₦ = 1

let ৲ = 1

let ৳ = 1

let ૱ = 1

let ௹ = 1

let ₹ = 1

let ₲ = 1

let ₪ = 1

let ₡ = 1

let ₫ = 1

let ៛ = 1

let ₵ = 1

let ₢ = 1

let ₸ = 1

let ₤ = 1

let ₳ = 1

let ₥ = 1

let ₠ = 1

let ₣ = 1

let ₰ = 1

let ₧ = 1

let ₯ = 1

let ₶ = 1

print("₶ = \(₶)")

print(₶+₶+₶)

And finally, there is the very weird Rial Sign: ﷼
It is ok to use it as an variable name too (again, according to Xcode8.1B3).
But when trying to use it, Xcode switches to right-to-left mode, which
makes for strange (for my occidental eyes) behaviour and display. All the
following is OK in Xcode:

// unusual Xcode right-to-left behavior with Rial Sign

let ﷼ = 21


print("﷼= \(﷼)") // will print ﷼= 21

Of course, this is just a data point, and Xcode8.1B3 should not be the
arbiter here. But I believe whether Swift accepts currency symbols as
variable names should be consistent. Either it accepts all of them, or it
includes all of them.

I see no reason to exclude them. On the contrary, it was a design feature
of Swift to relieve use from the shackles of the ASCII character set.

In conclusion, I believe this proposal must be accepted, and actually
expanded to include ¥, ¢, £, and also to make it explicit that currency
symbols can be used in variable names as first and only character, as first
of many characters, and at any position.

This would make $0, $1, $2… legal variable names. I believe this is OK.

What would happen to implicitly declared closure parameters then? Nothing.
They would continue to be implicitly declared in the context of closures
that do not declare their parameters explicitly, similarly to `self` being
implicitly declared in the context of a class. A user willing to use $0
there would be facing a name collision, which is OK.

Note that such a change is purely additive: no legal source code today
would fail with this change.

I hope that at the very least, I opened a new perspective on this proposal,
and I hope we can find a way to be less culturally biased.

Jean-Denis

* What is your evaluation of the proposal?

+1. However, it should be expanded to include all Unicode currency symbols.

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

Very much so, because it reveals a significant inconsistency in the way the
language handles characters for identifiers.

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

Very much so, considering the language made a point to support unicode
characters in identifiers, and '$' should behave consistently with the
other Unicode currency symbols.

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

In the specific case, this is irrelevant. We are in territory only treaded
by Swift

* How much effort did you put 

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Georgios Moschovitis via swift-evolution]

> I'd almost always prefer to have another three lines of a protocolvisible, 
> than three lines of imports. 

Maybe you just need an editor that can fold the imports (e.g. JetBrains)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution