Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm against this, because I often write extensions on Apple classes (like, say, UIColor) that are only intended to be used from Swift, in a pure-Swift project, and I need no stinking' @nonobjc in there. How much of a problem can this surprise be? You call a method, the compiler tells you it's

Re: [swift-evolution] Lambda function syntax

One thing I'm really bothered by in C# and ES6 are no-argument methods: () => { foo() } // GROSS The syntax of C# isn't so bad, though, when there's no return type: foo.map((bar) => bar.boz) but those double-parens bother me and my eyes a bit, so this definitely looks better: foo.map {

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> I don’t see how this: > > protocol P { > type/*alias*/ A > } > > struct X : P { > struct A {} > } > > is fundamentally any different from: > > protocol P { > func f() > } > > struct X : P { > func f() {} > } > > What am I missing? I'd say it's the fact that adding an associated

Re: [swift-evolution] Brace syntax

> I don't know many people who have experienced a large variety (8+?) of > programming languages and prefer Python's forced indentation Count me as one. I'd prefer Swift to have Python-style indentation, just on the grounds of braces being stupid (why would you want to enter the same scope

Re: [swift-evolution] Final by default for classes and methods

> Isn't this proposal solving a problem that in practice doesn't exist or isn't > common enough to be worth a language level fix? Well I have a TextExpander macro that inserts "// override point" when I type ;overp. Been marking all overridable methods this way for years. I think it's an

Re: [swift-evolution] Final by default for classes and methods

> Aren't we mixing up two different issues here? "Having a default final for > Swift classes" should be treated as a separate issue from "Apple frameworks > should stay overridable". I have to agree, and so I'll change my vote to +1. > 1. Within a module, should I be able to override my own

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

> My experience with other languages is that [...] unless you're a Boost > maintainer, people tend to target one version of the language anyway, either > the older one using a workaround portable to the newer version, or the new > version without regards to people stuck behind. That's not how

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

> I personally like it because I consider the defaulted parameters to be “extra > add-ons” or the alternative to a “userInfo: [String: AnyObject]” pattern. > > I’d vote to leave things as-is unless it imposes a significant maintenance > cost on the compiler. Strong +1. Please leave it be, it's

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

> public > filewide > modulewide > private > > Don’t bother me because they seem to be part of the word. The way > “nationwide” does, they are made up words but intent is clear. I could live with filewide and modulewide instead of fileprivate and moduleprivate. I still prefer the latter

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

> The problem with protected is that it provides virtually no protection at > all; you can trivially expose it in a derived class + > Extensions further dilute the enforceability of "protected", since anyone > would be able to use an extension to dump methods into a class's namespace > and

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

I'm missing those optional methods too, but protocol extensions sound like a better solution for this. (For those suggesting a separate protocol, consider UITableView. How many protocols would it take to model all the optional delegate methods as separate protocols? Certainly more than 10,

Re: [swift-evolution] struct subtyping

+1, would love this. A. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Adding a Build Configuration Import Test

Strong +1, very useful. Perhaps importable instead of canImport? Looks and reads better: // UXKit at WWDC'16, pretty please! #if importable(UIKit) typealias UXColor = UIColor #elseif importable(Cocoa) typealias UXColor = NSColor #else // meh #endif A.

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

Just thinking out loud — ‘dynamic’ as an attribute on an object, allowing arbitrary method calls that are dispatched dynamically... let foo: @dynamic AnyObject = Foo() foo.someWeirdMethod() for thing in things { (thing as @dynamic).bar() } Dynamic as a type: let foo: dynamic = Foo()

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

Pedro, endIndex is exclusive by definition. You can iterate over any collection by going from startIndex until you reach endIndex. If we change endIndex on ranges, *all* generic iteration code will be broken when dealing with ranges, even the for statement. I understand that there are two

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

Honestly, we really need this for a lot of different cases: > * Allow you to attach member definitions to particular cases. It would be an > error if they didn't all define the same members, unless there was a > top-level catchall. > >enum Suit: Int { >var isRed: Bool { return

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

> What is your evaluation of the proposal? -0.5 if the annotation is verbose (much longer than @discardable). +0.5 if the annotation is pleasant and concise, like @discardable > Is the problem being addressed significant enough to warrant a change to > Swift? The warn-by-default behavior is

Re: [swift-evolution] [Pitch] Change the endIndex value for closed Ranges and Collections

PS: > endIndex is exclusive by definition If you want a rationale on this... 1) It's how cursors typically work, and people familiar with the concept already expect this. 2) It's often the most convenient choice. Back in the day, you would write C code like this: for (int *cur =

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

+1, but > Expand the scope of “if” and “while” statements +2 for this. At least a dozen times I've been beaten by changing let foo = bar.map { ...} into if let foo = bar.map { ...} { ... } only to find myself with a compiler error (because my brain just doesn't register this

Re: [swift-evolution] idea: immutable setters for structs and tuples?

> I would very much like a standardized way of doing this. +1 for a function like with/lens in stdlib. A. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Alternate proposal for multi-line string literial

Feels wrong to me. It's ugly (looks like line noise) and unnecessary (this much flexibility isn't required in practice). Making features more powerful doesn't always make them better. Some of the use cases you have in mind are probably better handled by macros, whenever they make it into

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

Coming in late, but: * “internal”, as already mentioned, has prior art as meaning “private to a package/project”, so should stay as it is * fileprivate looks good, obvious, straightforward and googlable to me * private(file) introduces a bunch of visual noise that I don't like * whoo-hoo, this

Re: [swift-evolution] Promote "primitive" types to enums in extensions

> I think I may be similarly misunderstanding your proposal; your intention > then is to import the type as an enum with raw value (to facilitate the > conversion to/from the C code) but without exposing that raw value on the > Swift side? > > In that case I think I’m in favour. Me too. But

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

> Sure, but is that worth 7 to 9 extra characters at every single use site for > something that's actually pretty common? Yes. These are special cases — both file-private and module-private is something that is fairly unusual and should stick out a bit, so the length helps here. (Unless

Re: [swift-evolution] Rewrite imported C function signatures

Reposting my comment from that other thread: [...] it's more of an external annotation on C code, something that we don't currently support for user code. (My understanding is that they have it implemented for Apple frameworks.) Perhaps, with Swift 3 going Linux, with should expose the ability

Re: [swift-evolution] Add an ifPresent function to Optional

> No. My argument is that map on collections and on optionals are two > completely different things. They unify on a level that does not > exist in Swift (higher-kinded types). +1000. Optional.map is already highly unfortunate. It makes optional arrays especially painful to deal with, but

Re: [swift-evolution] Pre-proposal: Safer Decimal Calculations

I have no stake in this proposal, except for: > I suggest, therefore, that this acceptance be indicated by > an annotation to the literal; a form such as ~0.1 might be easiest to > read and implement, as the prefix ~ operator currently has no meaning > for a floating-point value. Whatever you

Re: [swift-evolution] Deprecating Trailing Closures

> I use trailing closures all the time because I find the brackets too noisy, > like ; at the end of a line is too noisy. The sort of code I use is: > > let foo = myArray > .filter { $0 & 1 == 1 } > .map { $0 + 1 } > .reduce(0) { $0 + $1 } +1 to this. Please don't

Re: [swift-evolution] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

>> The new default is better for: >> >> - (A) classes that provide both mutating and non-mutating methods; >> - (B) methods where forgetting to use the result produces a bug (a >> download task that needs to be resumed, an alert that needs to be >> displayed, a listener that needs to be stored

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

> Why is it important to highlight word boundaries in so many other conventions > in Swift but not in this one? What would be lost with this alternative? > > public > module_private > file_private > private > > Is it just the extra (chorded, on US keyboards) keystroke? I think the >

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

>> My point is that "protected" *isn't* access control. If we added it, it >> would have to be as an independent modifier. Private/internal/public >> fundamentally affect semantics—private and internal code is only accessible >> within a module, so we have full knowledge of their use sites at

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

> Protocol requirements with default (no-op) implementations already satisfy > that design goal, no? Chris, as we've discussed in a thread that I think got forked from this one: Yes, they do technically, but it would be nice to both: 1) make it an obvious documented part of the signature,

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

>> I've actually had multiple cases in Objective-C code where this feature >> (some object behaving differently depending on wether or not a delegate >> method has been implemented) has prevented me from implementing features the >> easy and obvious way. In those cases I resorted to

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

> I do not understand why an optional method should require a default value. > That’s not how optional methods work in Objective-C where the caller will ask > whether the method is implemented and calls it or does something else. With a > default value it would be much more difficult to do

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

> Some ideas I was thinking about for optional protocol functions was you’d > declare it like this: > > protocol UIGestureRecognizerDelegate { > optional func gestureRecognizerShouldBegin(gestureRecognizer: > UIGestureRecognizer) -> Bool = true > } > > If you put “optional” there, the

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

I understand the concern. To me, the answer is clearly yes. The language cannot be considered in isolation from its use cases; imagine UIKit written in Swift. You want the developers to be able to quickly understand which table view delegate methods they need to implement, and what the

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

> I'd prefer a more general solution instead of introducing the notion of an > "optional" function: just make it possible to write default implementations > inline in a protocol definition. This would work, too. I guess there's no need for an “optional” keyword if the implementation is right

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> My preference would be for there to be only one Self, and have it always be > the dynamic type of 'self'. Some people disagree, but I don't think it's all > that onerous to have to write ClassName.foo if that's really what you > specifically mean. +1. There's just no way we want to explain

Re: [swift-evolution] [Review] SE-0026 Abstract classes and methods

> This should be resolved when PwS > (Protocol with > Storage) get alive: > > // Framework land > public protocol DatabaseRecord { > internal extension DatabaseRecord { > var referenceRow:

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

> My understanding is that this comes about from a simple idea - someone wants > to have objects which have some protection of their API from the outside > world, and to limit the interface between those objects from exposing > internal implementation details in order to maintain invariance.

Re: [swift-evolution] Hidden initiallizations ...

This is idiomatic Swift. I see no readability issues with that. Of course, shadowing a local var with a for loop counter is another case. I'd say a warning is warranted there. A. > On Mar 29, 2016, at 5:30 PM, Biala wrote: > > And you are OK with that > I can not

Re: [swift-evolution] Hidden initiallizations ...

> Actually I use a lot of Applescript style naming, though admittedly I can be > a bit inconsistent about it. For example, I like using eachFoo as a name for > a loop variable like so: > > for eachIndex in 1 ..< 100 { … } > > Which can read nicely as natural language, but since I don’t

Re: [swift-evolution] Protected access level / multiple class/struct/protocol APIs

Let me bump this thread. How do we move forward? Here's an interface of another Swift class I've just made (slowly rewriting my Obj-C components to Swift here): public class SoloContainerViewController: UIViewController { private var _contentViewController: UIViewController? public

Re: [swift-evolution] SE-0066 Reaction

Hey, I'm inserting these opinions into almost every FP discussion, for which I'm sorry, but I believe it's important to remind everyone that there's the rest of us who will run away from Swift if it becomes too FP-y. > One of the things that I have noticed over the last year or so of working

Re: [swift-evolution] TreeLiteralConvertible

Hey, Milos! Can you please give us a few real-world examples where initializing a nontrivial tree-like data structure in code would be useful? It's an honest question — I have never felt the need in my life, and I always preferred to move the data into something like a bundled json or CSV,

Re: [swift-evolution] What about a VBA style with Statement?

>> I also like the idea of a dedicated method-cascading operator, like what >> Dart has. It eliminates the need for a programmer to explicitly remember to >> 'return self' at the end of a chainable method. Not sure how well it'd >> integrate with SE-0047 (@discardableResult) though. > >

Re: [swift-evolution] TreeLiteralConvertible

Hey! >> Can you please give us a few real-world examples where initializing a >> nontrivial tree-like data structure in code would be useful? > > I suppose we always prefer to move *all* data into databases or files with > dedicated data formats, *including* arrays, strings, dictionaries, etc.

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

Chris, > Given all this, I think it makes sense to go for syntactic uniformity between > parameter list and function types, and just require parenthesis on the > argument list. The types above can be trivially written as: > > (Int) -> Float > (String) -> () I don't care about this

Re: [swift-evolution] [Pitch] Rename `x.dynamicType` to `x.Self`

> I do not think that I was conflating these two aspects. Using #type(self) > would return the particular type of the current instance (dynamic type) while > using #type(A.var) would return the declared (static) type of the property. Taras, to me personally, #something suggests evaluation at

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

> What is your evaluation of the proposal? Very strong -1. Drew has said it all. A few extra points: * If you split a class into a bunch of extensions, chances are it's a large class, and fileprivate keyword provides crucial *documentation* on which methods and fields are accessed