Re: [swift-evolution] Swift-Native Alternative to KVO

> On Jan 1, 2016, at 7:00 PM, Jared Sinclair via swift-evolution > wrote: > > The one-to-many observer pattern could really use a first-party, native Swift > solution. The day-to-day practice of writing iOS / OS X applications needs > it, and we end up falling back

Re: [swift-evolution] Better syntax for deferred?

> On Jan 2, 2016, at 8:37 AM, Tino Heth via swift-evolution > wrote: > >> >> Unless I missed something obvious, wouldn't placing "code that always has to >> run at the end" actually *at the end* not make more sense? Like this… > In most cases, you use defer for

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

> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution > wrote: > > There is no direct way to implement Objective-C entry points for protocol > extensions. One would effectively have to install a category on every > Objective-C root class [*] with the

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 8:56 AM, Greg Parker via swift-evolution > wrote: > >> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >> > wrote: >> >> I remember this being discussed in the

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

> On Jan 5, 2016, at 9:06 PM, Félix Cloutier wrote: > > The linker is smart enough to get rid of frameworks that you don't actually > use. > > Félix objc_copyClassList leaves a value of 14694 in classCount. When I just link against Foundation it only gives 1581. otool

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

> On Jan 5, 2016, at 8:29 PM, Greg Parker <gpar...@apple.com> wrote: > >> >> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Ja

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Strong +1 on this proposal. I use Objective-C’s forwarding mechanisms quite often in my custom view code, in order to separate the code managing the outer view, the layout of subviews within the view, and business logic into separate classes, all while presenting a single, monolithic interface

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

> On Jan 5, 2016, at 8:55 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Jan 5, 2016, at 8:29 PM, Greg Parker <gpar...@apple.com >> <mailto:gpar...@apple.com>> wrote: >> >>> >>> On Jan 5, 2

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 1:34 PM, T.J. Usiyan <griotsp...@gmail.com> wrote: > > On Wed, Jan 6, 2016 at 2:18 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > I just spent a half hour last nigh

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

I agree with this. -1 to the proposal. Charles > On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution > wrote: > > To play devils advocate, take for example UINavigationController in UIKit on > iOS. > > I’ve seen multiple times in multiple projects

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 20, 2015, at 3:14 AM, Brent Royal-Gordon > wrote: > > Anyway, my point remains: this _SwiftNativeNSError should use a userInfo > property on your ErrorType to populate NSError.userInfo. There should be no > need to go through the full rigamarole of calling

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

> On Dec 23, 2015, at 1:12 PM, Felipe Cypriano via swift-evolution > wrote: > > On Wed, Dec 23, 2015, at 09:25, Tino Heth wrote: >> >>> The benefits of it far out weight the fears of having it. >> so what is the practical problem that's solved by final that convinced

Re: [swift-evolution] [Review] Require self for accessing instance members

> On Dec 19, 2015, at 12:23 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Dec 19, 2015, at 3:02 AM, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> >> wrote: >> >> imho the most valuable vote for mandatory

[swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

This is a bit of a pre-proposal; I wanted to bounce some ideas off the community before writing up a formal proposal, to see how people felt about this. The Problem: Swift introduces the very nifty ErrorType protocol, which, if implemented as an enum, allows one to associate arguments with

Re: [swift-evolution] Brace syntax

> On Dec 19, 2015, at 7:39 PM, Alexander Regueiro via swift-evolution > wrote: > > Has anyone considered removing braces from the Swift language? The main > alternative would be indentation-based scoping like in Python or Ruby. No. No no no no no no no. No. Please,

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 20, 2015, at 12:35 AM, Brent Royal-Gordon > wrote: > > I don't know if it can actually be private, but it should be invisible to > developers, and considered an implementation detail. It might also make sense > to retrieve the `userInfo` from `swiftError` on

Re: [swift-evolution] rename dropFirst() and dropLast()

> On Dec 28, 2015, at 6:19 PM, Michel Fortin via swift-evolution > wrote: > > Really? The convention says: "When a mutating method is described by a verb, > name its non-mutating counterpart according to the “ed/ing” rule, e.g. the > non-mutating versions of

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 21, 2015, at 5:36 PM, Colin Cornaby wrote: > > So here’s my 2 cents. I talked to Charles about this off list, so I’ll just > say my piece and then move along. :) > > It seems to me that ErrorType is very empty because it’s meant to be a > placeholder in the

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

The frameworks remaining useful simply because they happen to be written in a different language would be a pretty sad state of affairs, IMO. Charles > On Dec 23, 2015, at 1:30 PM, Felipe Cypriano wrote: > > Sounds like you are going to continue using Objective-C until you

Re: [swift-evolution] Pre-proposal: Convert reference params to tuples

> On Dec 23, 2015, at 5:11 AM, Tino Heth <2...@gmx.de> wrote: > > Imho it sounds good, but I rarely encounter situations where I would benefit > from the proposed change… It does happen in the Objective-C frameworks; the NSURL example I provided is an aggravatingly common one, but there are

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

> On Dec 23, 2015, at 8:15 PM, Matthew Johnson via swift-evolution > wrote: > > I’m not trying to force my opinion on anyone. I’m just making a case for the > advantages of a particular default. Changing the default does not break > inheritance at all. Nobody has

[swift-evolution] Pitch: Deinit for structs

Introduction: This is a rather simple proposal, requesting that structs allow the ‘deinit’ destructor, as classes currently do. Motivation: Sometimes it is necessary to create an object that wraps a network connection (that needs to be closed when the object is destroyed), or that writes to a

[swift-evolution] Pitch: Copy constructors for structs

Introduction: This is a request for a copy constructor mechanism for structs in Swift. Motivation: Suppose you have a class stored inside a struct, like so: class C { func copy() -> C { … } } struct S { var i: Int var c: C } and you create a couple of the structs,

Re: [swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

> On Dec 23, 2015, at 7:50 PM, Félix Cloutier via swift-evolution > wrote: > > The & operator isn't exactly an address-of operator. Does [0] even return > a pointer to the inner buffer? When you use & with properties (and possibly > with subscripts as well), Swift

[swift-evolution] Pitch: @required attribute for closures

MOTIVATION: As per the current situation, there is a pitfall when writing asynchronous APIs that does not occur when writing synchronous APIs. Consider the following synchronous API: func doSomething() -> SomeEnum { if aCondition { if bCondition {

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 10:28 AM, Michael Peternell > wrote: > > This is not a good design. If you want the completion handler to be called, > you can rewrite the function to make this intent obvious: > > func doSomethingAsync(completionHandler: (SomeEnum) -> ()) { >

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution >> > wrote: >> >> The following names were suggested: NoReturn,

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Am 07.06.2016 um 19:45 sch

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:56 PM, Xiaodi Wu wrote: > > No doubt, @noreturn is clearer today, but how much of that is because it's > what we already know? None. It’s clearer because it does exactly what it says on the tin. Show it to someone who’s familiar with the concept of

Re: [swift-evolution] Pitch: @required attribute for closures

On Jun 6, 2016, at 2:49 PM, Michael Peternell wrote: > > That's really hard to answer in the general case. I think real proposals > should contain concrete, realistic examples that show the benefit of the > proposal. It's really hard to argue against a proposal if

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 6, 2016, at 3:48 PM, michael.petern...@gmx.at wrote: > > Yes, ok... > > Well, I cannot easily make everything synchronous. I just can change it in a > way that makes a `@required` attribute "optional" ;) > > import Foundation > > enum Result { >case success(T) >case

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

> On Jun 12, 2016, at 11:27 PM, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution >> > wrote: >> >> I just installed the current Swift 3

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 5:46 PM, michael.petern...@gmx.at wrote: > >> Am 05.06.2016 um 20:31 schrieb Charlie Monroe via swift-evolution >> >: >> >> While I agree with Michael that nowadays, a lot of stuff that doesn't need >> to be, is

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> I disagree. We are discussing how to annotate a function in some way so that >> the compiler knows that the code following it will never be executed *and* >> so a human who reads the

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 3:42 AM, Tino Heth via swift-evolution > wrote: > >> I can't reply directly to all the points in this thread, but I will just say >> that there are ways of emulating protected in the language as it exists >> today: >> >> If the goal is to have

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > > But `protected` is quite different from other access levels; it does not > limit the visibility of the symbols, but rather their use. And protocols face > the same sort of problem as

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

A huge +1 on the syntax change, which I think is a colossal improvement over the current situation and adds a lot of clarity to enum declarations. Neutral on the necessity to add actual stored properties to the enums. If the new syntax were merely syntactic sugar that would effectively generate

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 9:31 AM, plx via swift-evolution > wrote: > > For the Sequence/Collection it’s a lot of work for IMHO a rather minor > convenience, but for more-complex type associated-type relationships it could > start to pay its own way. Is it really that

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 1:53 PM, Xiaodi Wu wrote: > > Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: > > func doSomething< > S: Sequence, T: Sequence, U: Sequence > >(foos: S, bars: T, bazzes: U) > where S.Element == Foo, T.Element == Bar,

[swift-evolution] Pitch: Small fix to where clauses in generics

Forgive me if this has already been proposed in one of the generics threads; I did a quick check and didn’t see anything. Currently, the code below does not compile: protocol P {} struct S: P {} extension SequenceType where Generator.Element: P { func foo() {} } func F(arr: [P]) {

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> On May 26, 2016, at 4:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > > - Abusing rawValue is just that: an abuse. In addition, enums with associated types can’t have rawValues. Why is this relevant, you may ask? Because error enums are a huge use case

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 11:23 AM, Tino Heth <2...@gmx.de> wrote: > >> Couldn’t you use the same reasoning to claim there shouldn’t be access >> control at all? Just add documention on methods you want to mark private >> telling users of the library not to call them! > > I guess you are making

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 2:02 PM, Tino Heth <2...@gmx.de> wrote: > >> The purpose of access control isn’t really to keep out malicious users, >> though, it’s to prevent accidental misuse and clarify the interface. > mh, I would call this a "documenting intend" ;-) If you get the method as an

Re: [swift-evolution] Enhanced existential types proposal discussion

Forgive me if this has already come up, but since we’re talking about fixing generics, I wonder if there is any solution in the pipeline for this problem: -- protocol P { func foo() } struct S: P { func foo() { print("foo") } } func doSomething(c: C) { for each in c {

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: > > I think the problem here is that P == P is true, but P : P is not (a protocol > does not conform to itself). But if you have a variable, parameter, etc. typed as P, that’s *not* the protocol, since protocols aren’t

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 29, 2016, at 9:20 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On May 29, 2016, at 5:

Re: [swift-evolution] Enhanced existential types proposal discussion

<matt...@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> >>> On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On Jun 22, 2016, at 1:28 AM, Douglas Gregor <dgre...@apple.com> wrote: > > On Jun 20, 2016, at 11:03 AM, Charles Srstka via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> It was deferred until after Swift 3.0

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

12:51 PM, Shawn Erickson <shaw...@gmail.com> wrote: > > I am curious on the disposition of this discussion / proposal pitch. Has any > additional effort taken place since this email thread tampered off? > > On Sat, May 14, 2016 at 2:40 AM Charles Srstka via swift-evolution

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 10:46 PM, Robert Widmann wrote: > > That is a different discussion entirely. Once you fall below internal then > we do not default to internal, we default to the maximum access level of the > outer decl. Read that linked part of the type

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 11:04 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > Result is that the property is only accessible from inside its parent type. *inside the type’s parent type Charles _

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 11:16 PM, Robert Widmann wrote: > > Charles we've diverged from the actual issue at hand to nitpick my English. > Read the code (that std::min tho!). We have a problem here and no obvious > solution that doesn't involve special-casing parts of

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 15, 2016, at 8:36 PM, Robert Widmann wrote: > > Point 3 is *not* how member lookup applies access control levels to > unannotated properties of outer structures (see >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

I think you guys are making this more complicated than it is. The rules here seem fairly simple: 1. The default access level is “internal”. 2. A type declared “private” at the top level will be visible to the file only. 3. If they are not given an access level, properties declared on the type

Re: [swift-evolution] [Proposal draft] NSError bridging

Obviously, I’m in favor of this one. +1! I think I did prefer the older name of CustomUserInfoError for the domain/code/userInfo protocol, rather than CustomNSError. This is just because I’d like to be able to do a global search through my project for “NSError” and have it turn up empty. Maybe

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

I like it. Accidental capture of a variable is probably one of the primary causes of retain cycles in modern Swift code. Requiring the capture to be explicit would take a lot of the surprise out of it and force the developer to think about the capture semantics. +1. Charles > On Jun 26,

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 24, 2016, at 8:27 AM, Vladimir.S via swift-evolution > wrote: > > (Personally I really don't understand why we need anything than ASCII codes > for identifiers. This could solve all the problems with invisible > space/left-to-right-flags/complicated

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

> On Mar 23, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution > wrote: > > * 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

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun Apr 10 2016, Dietmar Planitzer > wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>>

Re: [swift-evolution] [Draft] Abolish IUO type

If you know something’s non-null, is there any advantage to keeping it in an implicitly-unwrapped optional instead of a normal non-optional type? Charles > On Mar 17, 2016, at 11:08 PM, Step C via swift-evolution > wrote: > > That just forces the unwrap to the base

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

While this style works, and definitely can substitute for a classical for loop, it is not quite as nice, because it cannot limit i’s scope to the loop. The variable will be visible outside of the loop body. Charles > On Apr 2, 2016, at 8:43 PM, Andrew Bennett via swift-evolution >

Re: [swift-evolution] Revisiting 0004, 0007 etc. - Swift deprecations

> On Apr 3, 2016, at 8:51 PM, David Waite via swift-evolution > wrote: > > Swift also has the benefit of built-in access to C/C++ and in some > environments Objective-C code and libraries. This means it does not have to > strive to either replace or to have

Re: [swift-evolution] [pre-proposal] Automatic unwrapper boolean properties using unless keyword

What I often do is use ?? to provide a default (usually false). if myList?.isEmpty ?? false { print(“Empty”) } else { print(“Not empty”) } The other thing you can do, of course, is to use a ‘where’ statement: if let list = myList where list.isEmpty { print(“Empty”) } else {

Re: [swift-evolution] [pre-proposal] Automatic unwrapper boolean properties using unless keyword

> On Mar 31, 2016, at 5:04 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > What I often do is use ?? to provide a default (usually false). > > if myList?.isEmpty ?? false { > print(“Empty”) > } else { > print(“N

Re: [swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

The correctness of this proposal seems somewhat self-evident. +1. Charles > On Mar 31, 2016, at 10:41 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance > Member

Re: [swift-evolution] Mutability for Foundation types in Swift

One comment: "In the most common case where a developer does not provide a custom reference type, then the backing store is our existing NSData and NSMutableData implementations. This consolidates logic into one place and provides cheap bridging in many cases (see Bridging for more

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 22, 2016, at 5:05 PM, Greg Parker <gpar...@apple.com> wrote: > >> On Apr 22, 2016, at 2:36 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> One comment: >&g

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 11:49 AM, Douglas Gregor via swift-evolution > wrote: > >> (Tangentially, why not introduce a required "override" keyword for >> conforming types that implement a version of a member introduced in protocol >> extensions? This would match the

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

> On Apr 27, 2016, at 9:30 AM, Andrew Bennett via swift-evolution > wrote: > > Sorry if this has been discussed, but have you considered dropping optional > entirely, making it throw, and a default implementation that throws a > selector not found exception? > >

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Why would you want lack of an optional method to be a fatal error, either? Charles > On Apr 27, 2016, at 5:29 PM, Andrew Bennett wrote: > > Hi Charles, > > My initial idea just had a fatalError, without a throw. It's better IMO, but > less Swift-y. It's not obvious from the

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I would prefer the “override” only apply to methods that already had default protocol implementations, because then it could help avoid the mistake of overriding a default implementation that you didn’t realize was there, thinking that this was a method that you needed to supply. Charles > On

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

As another colorblind developer, this kind of is an issue. While I *can* discern colors, the only one that sticks out strongly is blue. If you’ve got reds, greens, browns, or oranges, my experience will be on a continuum from “I think that’s red?” in the best case, “I can figure this out if I

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 24, 2016, at 5:45 PM, Haravikk via swift-evolution > wrote: > >> On 24 May 2016, at 21:14, Leonardo Pessoa > > wrote: >> >> My first question here would be "what's the gain?" I understand >> CollectionTypes and

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

And that works about 30% of the time, if you’re being generous. Charles > On May 18, 2016, at 1:20 PM, Karl via swift-evolution > wrote: > > Since you’re using OSX - CMD + click, jumps to definition. > >> On 18 May 2016, at 07:09, Krystof Vasa via swift-evolution

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

+1 from me as well. All these “Optional(foo)” things showing up in user-facing strings are a pain, and since they don’t show up until runtime, it’s really easy to miss them. Charles > On May 18, 2016, at 1:50 PM, Krystof Vasa via swift-evolution > wrote: > > The

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

Put me firmly in the pro-warning camp. If enforcing manual synthesis of ivars (something I never understood the brouhaha about) warranted a warning flag in clang, I think requiring self should at least merit consideration. It certainly has a much greater potential for bugs than automatic ivar

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

> On May 19, 2016, at 2:15 PM, Michael Peternell via swift-evolution > wrote: > > The problem that SE-0009 tries to solve is that when looking at a line in > isolation, like > >print(foo) > > there is no way to tell wether foo is an iVar, a local var or a

Re: [swift-evolution] [proposal] default returns

> On May 10, 2016, at 7:11 PM, Eduardo Mourey Lopez Ne via swift-evolution > wrote: > > current: > func myComplexOperation() -> Int { > //Some long complex code that might return some value > //Default return at the very end > return 0 > } > >

Re: [swift-evolution] [proposal] extra if syntax

> On May 10, 2016, at 1:10 PM, MobileSoft (Piotr) via swift-evolution > wrote: > > I think that should be added new ‘postfix’ if syntax: > a = 5 if b == x > > the code will be better readable. For example: > > a = 5 if b == x > c = 6 > d = 8 > e = 10 if y == true >

[swift-evolution] Why can't protocols define constants or subtypes?

With a class or a struct, I can nest constants and subtypes within the type, like so: class MyWidget { static let SomeConstant = “This string is useful to subclasses of MyWidget somehow" enum Type { case Cog case Sprocket }

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution > wrote: > >> I'm not an expert in the Linux communities needs and desires. That said, >> from what I understand, they don’t care at all about ABI stability, since >> everything is typically built from

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 6, 2016, at 10:16 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >&

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 14, 2016, at 3:51 AM, Michael Peternell > wrote: > > For interoperability, ErrorType and NSError should be toll-free-bridged, like > CFStringRef and NSString. Converting between them should be a no-op at > runtime. That would be technically infeasible

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

On May 14, 2016, at 12:19 AM, Jon Shier via swift-evolution wrote: > > Charles: > I appreciate the attempt to minimize a current pain point and I agree > on most of your analysis of the current NSError bridging but I think your > proposal is fundamentally

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 14, 2016, at 1:45 AM, Jon Shier via swift-evolution > wrote: > > Charles: > Foundation error reporting is based on NSError, nothing else. In none > of my apps have I used my own NSError’s and in the few frameworks I use or > maintain, few use NSError,

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Here’s another argument in favor of the pitch: Take an array: let array = ["Foo", "Bar”] We can convert this to an NSArray via the bridge: let nsArray = array as NSArray We can also convert this to a CFArray: let cfArray = array as CFArray Now, let’s convert them back. let nsUntypedArray =

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

Count me among those who had no idea this feature even existed. The thing about the current behavior that strikes me as odd is that it only applies to parameters with default values. So foo(a: Int = 1, b: Int = 2) is reorderable, whereas foo(a: Int, b: Int) is not. This seems fairly

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

Is the proposal to add these initializers to protocols like IntegerType, or just to individually add them to each of the numeric types? It’s unclear from the proposal, but in case that question hasn’t been decided yet, I’d like to vote for putting them in the protocols. It’s bugged me for a

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > > I formerly posted a less-fleshed-out version of this in the “Reducing > bridging magic” thread, but I thought this might warrant its own pitch. What > do you al

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

> On May 6, 2016, at 3:15 PM, Joe Groff via swift-evolution > wrote: > >> On May 6, 2016, at 12:21 PM, Jacob Bandes-Storch via swift-evolution >> > wrote: >> >> Does this affect the ability to use "x as?

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 4:48 PM, Erica Sadun via swift-evolution > wrote: > >> On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution >> > wrote: >>> NSError bridging can also be extracted from the

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 2, 2016, at 5:53 PM, Joe Groff via swift-evolution > wrote: > > I can't think of any problems that would block us from doing that today. It'd > be pretty easy to write an ErrorProtocol extension that just forwards > NSError's interface via bridging, and I

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

. Charles > On May 6, 2016, at 10:16 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >&

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

> On May 6, 2016, at 2:04 AM, Adrian Zubarev via swift-evolution > wrote: > > The ugly NSError pattern could be rewritten and migrated to: > > do { >try something() > } catch let error { >handle(error `bridge` NSError) > } > > Is such a change complicated,

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

I’m afraid I generally have to agree with this criticism. For types like NSURL which would make sense to become value types in the future, dropping the prefix does seem as if it would put constraints on future growth. I do think the enum hoisting is great, though, and if it were in a separate

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

On May 9, 2016, at 7:38 PM, Rod Brown via swift-evolution wrote: > > I am uncertain about the NSCoding proposition as it is not a generic concept > that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm > that seems to me should retain it’s NS

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

> On Apr 15, 2016, at 8:09 PM, Andrew Bennett via swift-evolution > wrote: > > I'm in support of a method of getting a sequence of (Index,Value) pairs (as > you know from the other thread). I think I'm leaning toward option three if > it's equivalent to

Re: [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types

* What is your evaluation of the proposal? Mixed. I definitely think we need the functionality, but I think naming it “Self” may be confusing, since it means “self” and “Self” will mean two distinct things, despite varying only in the case of the first letter. * Is the problem being addressed

Re: [swift-evolution] [Accepted] SE-0072: Fully eliminate implicit bridging conversions from Swift

On the downside: This is absolutely true. All of those conversions would be the first up against the well when the revolution comes. On the upside: I imagine a compiler warning could be pretty reasonably whipped up to detect these, and after the dust cleared, we’d be able to just try

Re: [swift-evolution] Dropping NS Prefix in Foundation

On May 6, 2016, at 5:06 PM, Tony Parker via swift-evolution wrote: > > Hi David, > >> On May 6, 2016, at 2:56 PM, David Waite > > wrote: >> >> -1 On the group as-is. I do not believe all of these

  1   2   3   4   >