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

on Thu Oct 20 2016, Guoye Zhang 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

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

> On Oct 20, 2016, at 8:25 AM, Haravikk via swift-evolution > wrote: > > >> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution >> wrote: >> >> Hello, >> >>> It's just that a common data type wasting almost half the space seems

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

> On 20 Oct 2016, at 15:51, Martin Waitz via swift-evolution > wrote: > > Hello, > >> It's just that a common data type wasting almost half the space seems >> inefficient. I guess this is also the reason why they didn't adopt optional >> integers widely in stdlib.

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

> 在 2016年10月20日，05:45，Jeremy Pereira 写道： > >> >> On 19 Oct 2016, at 16:13, Guoye Zhang wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via

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

Hello, It's just that a common data type wasting almost half the space seems inefficient. I guess this is also the reason why they didn't adopt optional integers widely in stdlib. When someone is really interested in fitting an optional integer into one machine word, then the best way would

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

> On 19 Oct 2016, at 16:13, Guoye Zhang wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>> >>> Currently, Swift Int family and

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

> 在 2016年10月19日，12:21，Joe Groff 写道： > >> >> On Oct 19, 2016, at 9:16 AM, Guoye Zhang via swift-evolution >> wrote: >> >>> >>> 在 2016年10月19日，11:43，Kevin Nattinger 写道： >>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang

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

on Wed Oct 19 2016, Kevin Nattinger wrote: >> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >> wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> > >>> On 18 Oct 2016, at

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

on Wed Oct 19 2016, Guoye Zhang wrote: >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>> >>> Currently, Swift Int family and

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

> On Oct 19, 2016, at 9:16 AM, Guoye Zhang via swift-evolution > wrote: > >> >> 在 2016年10月19日，11:43，Kevin Nattinger 写道： >> >>> >>> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >>> wrote: >>> >>>

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

> 在 2016年10月19日，11:43，Kevin Nattinger 写道： > >> >> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution >> wrote: >> >> >>> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >>> >>> On 18 Oct 2016, at

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

> On Oct 19, 2016, at 8:13 AM, Guoye Zhang via swift-evolution > wrote: > > >> 在 2016年10月19日，07:10，Jeremy Pereira 写道： >> >> >>> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >>> wrote: >>>

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

> 在 2016年10月19日，07:10，Jeremy Pereira 写道： > > >> On 18 Oct 2016, at 19:17, Guoye Zhang via swift-evolution >> wrote: >> >> Currently, Swift Int family and UInt family have compact representations >> that utilize all available

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

> On 18 Oct 2016, at 19:17, 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

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

> On 18 Oct 2016, at 20:46, Guoye Zhang via swift-evolution > wrote: > >> >> 在 2016年10月18日，15:30，David Waite > > 写道： >> >> >>> On Oct 18, 2016, at 12:17 PM, Guoye Zhang via swift-evolution >>>

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

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

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

> 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

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

> 在 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,

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

> 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

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

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

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

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

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

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

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

> 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

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

> 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

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

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 >

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

> 在 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)`, >

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

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)

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

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

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

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

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

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