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

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

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

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 Framew

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

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 ad

[swift-evolution] Swift Reflection

  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 dat

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

> > 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: ! & * ( . - Yo

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

* 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

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

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 s

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

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.

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

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

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

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 ex

[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 propos

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 val

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 special

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

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)`, > auto-boxing when nece

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 > efficiently? > > Nevin > > On Tues

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 optionals just to save a > Byte.

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 optional integers. It takes

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 would mess with NSNotFound wh

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 inherited from C. However, it is >> horribly ine

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 wo

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 in optionals. An additional

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, and UInt family would lose its largest >> value. Top val

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

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. Removing the first element of a Collection is potentially an O(n) operation. Using `popFirst` in a

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

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

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 this moment, though its usage

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

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 cir

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 spec

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

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

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

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

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

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 wit

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

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 se

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

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

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

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 ch

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

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 L

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

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 thin

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

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

[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Dear Swift-Evolution community, A few of us have been preparing a proposal to refine the definitions of identifiers & operators. This includes some changes to the permitted Unicode characters. The latest (perhaps final?) draft is available here: https://github.com/jtbandes/swift-evolution/blob/