Re: [swift-evolution] [Proposal Idea] dot shorthand for instance members

2015-12-18 Thread Rob Mayoff via swift-evolution
When you access a static member of a type using the dot shortcut, Swift evaluates the expression immediately. Are you proposing that when you access a member of an instance, Swift generate a closure? Or are you proposing that Swift generate a closure or not depending on how the expression's

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

2015-12-27 Thread Rob Mayoff via swift-evolution
Great idea, but why make it a free function instead of a Selector initializer? let sel1 = Selector(UIView.`insertSubview(_:at:)`) let sel2 = Selector(UIView.`frame.get`) Of course if there were such a thing as GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion to

Re: [swift-evolution] Proposal: Enum 'count' functionality

2015-12-23 Thread Rob Mayoff via swift-evolution
On Tue, Dec 22, 2015 at 12:33 AM, Zef Houssney via swift-evolution < swift-evolution@swift.org> wrote: > I agree with Stephen Celis that the best names for this (yet) are > definitely `cases` and optionally `rawValues` if the cases are > RawRepresentable. > That makes me want to say `for case in

Re: [swift-evolution] Lambda function syntax

2015-12-23 Thread Rob Mayoff via swift-evolution
> > The braces being around the type specifier as well as function body rather > bothers me. Surely it would be more consistent just to have the braces > around the function body, and then the type specifier preceding this? > If you mean consistency between closures and function declarations,

Re: [swift-evolution] Shorthand unwrap proposal

2016-06-24 Thread Rob Mayoff via swift-evolution
This is equivalent to the “Add an ifPresent function to Optional” suggestion made back in March. http://thread.gmane.org/gmane.comp.lang.swift.evolution/9173 Personally I'd prefer an `ifPresent` or `foreach` method to using `map`, as `ifPresent` or `foreach` would make it clearer to the reader

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

2016-03-18 Thread Rob Mayoff via swift-evolution
Option 2i is the only one that neither discards nor makes up information, and it doesn't seem like 2i would impose a significant burden on users.​ ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [proposal] Allow trailing closures in 'guard' conditions

2016-03-23 Thread Rob Mayoff via swift-evolution
I think there will be confusion if these statements are inconsistent regarding trailing closures. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

2016-04-01 Thread Rob Mayoff via swift-evolution
I would prefer the conditional statements to treat trailing closures consistently, rather than allow this minor but inconsistent convenience. I don't think this needs changing. I read the proposal and followed the list discussion. ___ swift-evolution

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

2016-04-01 Thread Rob Mayoff via swift-evolution
Check out the `testable` attribute: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Attributes.html#//apple_ref/doc/uid/TP40014097-CH35-ID347 Lots of examples if you type `swift testable` into your favorite search engine. On Fri, Apr 1, 2016 at

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

2016-04-01 Thread Rob Mayoff via swift-evolution
> > > class UITableView { > ... > private func addRow(at indexPath: NSIndexPath) { > ... > cell.size.height = delegate?.tableView(self, > heightForRowAtIndexPath: indexPath) ?? rowHeight >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

2016-04-22 Thread Rob Mayoff via swift-evolution
(-1)^sign * significand * radix^exponent Significand is not like the other two, I guess, since nothing is raised to it as a power... On Fri, Apr 22, 2016 at 11:42 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > A floating point number is made up > of three parts,

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

2016-05-23 Thread Rob Mayoff via swift-evolution
On Mon, May 23, 2016 at 12:26 PM, David Sweeris via swift-evolution wrote: > Dunno about other IDEs, but Xcode's syntax highlighting can change the size, > typeface (bold, italic, etc), and even the font. You can make instance > variables show up as 24pt comic sans,

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

2016-05-16 Thread Rob Mayoff via swift-evolution
We (you) shouldn't remove the NS prefixes from most of the classes in the proposal. I agree with the reasons the other naysayers have given, but I'll try to restate them in my own words. Swift needs a better namespace/import system before these classes should lose the NS prefix. Right now, you

Re: [swift-evolution] Removing Variadic Parameters.

2016-07-06 Thread Rob Mayoff via swift-evolution
On Wed, Jul 6, 2016 at 2:57 PM, Tino Heth via swift-evolution wrote: > Can you talk about concrete examples? Because Objective-C had no variadic > messages, it's natural that the feature isn't utilized in Cocoa Objective-C has variadic messages. I'd be surprised if

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

2016-07-11 Thread Rob Mayoff via swift-evolution
Just to be clear, under your proposal, what does the following program print? Can you make an argument in favor of your interpretation? var x = 1 switch x { case 1: print("one") x = 2 continue case 2: print("two") default: break }

Re: [swift-evolution] final + lazy + fileprivate modifiers

2017-02-17 Thread Rob Mayoff via swift-evolution
On Fri, Feb 17, 2017 at 3:56 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Here, a function call is an _intentional_ act. Writing a function not > meant to be called is an _intentional_ act. It is strange that you would > demand the compiler to stand between two of your

Re: [swift-evolution] Nil-rejection operator

2017-02-09 Thread Rob Mayoff via swift-evolution
On Thu, Feb 9, 2017 at 2:25 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I wonder if an alternative to the original proposal might be to allow > throw on the right hand side? So you could do: > > let y = x ?? throw myError > > You can do this today: extension Error {

Re: [swift-evolution] protocol-oriented integers (take 2)

2017-01-15 Thread Rob Mayoff via swift-evolution
On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > Oh... you mean that word(at:) itself would be linear, and thus > algorithms that iterate the words linearly would be O(N^2)... yuck. > Couldn't you fix this by replacing `func word(at n:

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

2016-10-20 Thread Rob Mayoff via swift-evolution
On Thu, Oct 20, 2016 at 9:29 AM, Jonathan S. Shapiro via swift-evolution < swift-evolution@swift.org> wrote: > Quick poll as a sanity check on a possible alternative for operators: > > If we admitted [:Sm:] and [:So:] and the traditional ASCII operator > characters, would that cover the things

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

2016-10-19 Thread Rob Mayoff via swift-evolution
On Wed, Oct 19, 2016 at 10:47 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > In any case, I’d specifically hate to lose these: > > - approximate equality: ≈ > - set operations: ∩, ∪ > - set relations: ⊂, ⊃, ⊄, ⊅, ⊆, ⊇, ⊈, ⊉, ⊊, ⊋ > - set membership: ∌, ∋, ∈, ∉ > - logical

Re: [swift-evolution] Allow ' in variable/constant names?

2017-01-11 Thread Rob Mayoff via swift-evolution
It's not as easy to type, but you can already use U+02B9 MODIFIER LETTER PRIME for this purpose. Swift accepts this: let x = 1 let xʹ = x + 1 let xʹʹ = xʹ + 1 let xʹʹʹ = xʹʹ + 1 On Wed, Jan 11, 2017 at 7:08 AM, Tuur Anton via swift-evolution < swift-evolution@swift.org> wrote: > I often have

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

2017-03-20 Thread Rob Mayoff via swift-evolution
I also disagree with the proposal, and Drew's explanation is spot on. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

2017-03-21 Thread Rob Mayoff via swift-evolution
On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution < swift-evolution@swift.org> wrote: > A core team member (I'm blanking on who) has pointed out that, in the end, > the only necessary access modifiers are public and not public (spelled > "internal" in Swift). > > > It is not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

2017-03-21 Thread Rob Mayoff via swift-evolution
On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > > The bug *does not affect what people use private for,* and so it *does not > affect anything in real-world use.* It’s less “the Finder makes your files > disappear on a regular basis” and

Re: [swift-evolution] class indent in swift, history?

2017-03-08 Thread Rob Mayoff via swift-evolution
On Wed, Mar 8, 2017 at 5:09 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > willSet and didSet have their own distinct scope; they execute > independently, however a switch statement is effectively a single scope > because of the ability to use fallthrough to visit later

Re: [swift-evolution] Specified Protocol Conformances in Subclasses

2017-03-10 Thread Rob Mayoff via swift-evolution
On Fri, Mar 10, 2017 at 6:08 AM, Rod Brown via swift-evolution < swift-evolution@swift.org> wrote: > Hi everyone. I found something odd that seems baked into how Cocoa Touch > does protocols, but Swift cannot model it: > > > @interface UIScrollView: UIView > > @property (weak, nonatomic) id

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

2017-07-25 Thread Rob Mayoff via swift-evolution
On Tue, Jul 25, 2017 at 4:44 AM, philohan95 via swift-evolution < swift-evolution@swift.org> wrote: > As you can see we had to use the properties twice (this would also be the > case of `if let`) making the initializer twice as long as necessary and > becomes a pain to implement when having more

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

2017-06-29 Thread Rob Mayoff via swift-evolution
On Wed, Jun 28, 2017 at 8:49 PM, Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > As the screener of a non-zero number of radars resulting from unwrapped > nils, I would certainly appreciate more use of guard let x = x else { > fatalError(“explanation”) } and hope that !! would

Re: [swift-evolution] [pitch] Comparison Reform

2017-04-25 Thread Rob Mayoff via swift-evolution
On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > I still think this is a naming conflict more than anything else. > > The first expectation is that equatable and comparable provides strict > equality and strict total ordering, and that those

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

2017-08-08 Thread Rob Mayoff via swift-evolution
On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users < swift-us...@swift.org> wrote: > > > On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < > swift-evolution@swift.org> wrote: > >> Yes, exactly. An Array is a struct wrapper for a reference type >> representing