Re: [swift-evolution] ternary operator ?: suggestion

For all the proposals I've seen on this topic, I have to say -1. While I agree with the notions surrounding this operator, I've yet to see a better alternative presented, and none that feel truly Swift. If someone has a great proposal, though, I look forward to seeing it. - Rod > On 5 Jan

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

>>* What is your evaluation of the proposal? +1 >>* Is the problem being addressed significant enough to warrant a change >> to Swift? Definitely. This is very confusing to have typealias mean two different things. >>* Does this proposal fit well with the feel and direction of

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

Sorry Brent, I obviously didn’t read down to the alternatives section. Stupid me. I think that it is a larger change, but if we’re going to change this, shouldn’t we do it right? From my perspective, a protocol says what “should” happen, whereas a type is where it eventually “does” happen. I

Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

It definitely is odd behaviour that needs to be sorted out. The question is, how? I think part of this is the confusing position that you put the code into. If I approached this new to Swift, I would expect the declaration in the type to be a replacement for a default in the protocol extension.

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

Brilliant. Makes sense and seems to be a best-of-both-worlds approach. - Rod On 2 Jan 2016, at 3:16 PM, Chris Lattner wrote: >>> On Jan 1, 2016, at 3:32 PM, Rod Brown wrote: >>> Thanks Chris. I want to figure out what the guiding principles are

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

Please see response inline - Rod > On 2 Jan 2016, at 9:13 AM, Erica Sadun via swift-evolution > wrote: > > Thanks Chris. I want to figure out what the guiding principles are before I > blow any further proposal-capital. This gives me a good place to start >

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

I definitely feel this is a great direction for a compromise. This outlines the issues involved well. Rod > On 1 Jan 2016, at 6:13 AM, Joe Groff via swift-evolution > wrote: > > A lot of the discussion around the final/sealed-by-default issue focused on > the

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

It comes down to a few issues: 1. Final exists in the language. This itself creates headaches for framework makers when their framework classes need to become “final” at a later stage. What do you do with the old subclasses in an app that shipped 5 years ago subclassing a now-final class? 2.

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

These arguments are definitely compelling. I would have to agree with this strongly. Very fair reasoning. > On 20 Dec 2015, at 2:21 PM, Jordan Rose via swift-evolution > wrote: > > >> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution >>

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

<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Dec 17, 2015, at 5:41 PM, Rod Brown via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> M

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

I must agree entirely with Brent’s assessment here. Can swift be a language that can go down as low-level as high performance computing? Absolutely. But need we tie our hands with the limitations as such? I don’t think so. Safety must give way to sensibility when the costs are this high. >

Re: [swift-evolution] WWDC Meetup

I'd be interested in catching up. Was curious if there was going to be a meet up, either formal or informal. Sounds good. -Rod > On 6 Jun 2016, at 5:36 PM, David Hart via swift-evolution > wrote: > > I imagine that during WWDC a non-negligible proportion of the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

Yes, I have to say Doug seems to be on the money with the concerns I hold with the current proposals about stripping out the "Objective-C Magic" in the bridge between Swift and Objective C. There seems to be a strong push recently to rip out these APIs with clearly well meaning intent, but

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

I have to agree with Charlie Monroe that while this is doable, it's clear this is a workaround to a problem, not a viable long term language solution. - Rod Sent from my iPhone > On 30 May 2016, at 2:49 PM, Callionica (Swift) > wrote: > > I've written up

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1. Completely agree with Brent's views here. On 28 May 2016, at 9:15 AM, Brent Royal-Gordon via swift-evolution wrote: >> The idea is simple: >> >>• Can we make return keyword optional in cases like this? >>• Shouldn’t this behave like @autoclosure or

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

I agree that we should be looking for what makes sense, not just what we’ve seen in other languages. That said, there seems a lot of hate for OOP in general that seems to be clouding people’s vision here. I think that “protected” as a form of access control is exactly what we want: rights that

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

Brent, You make a very good point about the fact internal is not necessarily the same as subclass, something I hadn’t considered. I think that the level of exposure these APIs then get - ultimately Public within frameworks - is too unrestricted. At least in Objective-C, we can vet the headers

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

> * What is your evaluation of the proposal? +1 I concur with David Hart: Foundation becoming the base first-class cross platform library seemed concerning when Foundation was build from a paradigm of “Object Everything”. This fits far better with the Swift philosophy of value types

Re: [swift-evolution] Auto Unwrapping Of Optionals

think a language feature like you describe would be a lot more helpful, but I'd love to hear others' views on that. - Rod > On 30 Apr 2016, at 5:22 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 29 Apr 2016, at 23:28, Rod Brown via swift-evolution >>

Re: [swift-evolution] Auto Unwrapping Of Optionals

Re-sent for Swift Evolution. Response at end. On 1 May 2016, at 6:31 AM, David Sweeris <daveswee...@mac.com> wrote: >> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I think this specific proposal aski

Re: [swift-evolution] [Review] SE-0032: Add find method to SequenceType

* What is your evaluation of the proposal? +1 for the functionality on CollectionType -1 for the functionality on SequenceType * Is the problem being addressed significant enough to warrant a change to Swift? It’s certainly a helpful addition and one I’ve got an analogous version of in my own

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

> What I'm saying is that I strongly prefer this: > >func print(_ values: Any..., separator: String, terminator: String) > > To this: > >func print(_ values: any..., separator: String, terminator: String) > > And that I think it would be confusing and unnecessarily duplicative to

Re: [swift-evolution] RFC: didset and willset

Agreed. Personally I prefer willSet and didSet, but consistency of rules is higher priority. +1. > On 19 May 2016, at 1:09 AM, Erica Sadun via swift-evolution > wrote: > > didSet and willSet remain outliers in the general rule of conjoined lowercase > keywords. Is

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

I think what you’re referring to as default values would be what you get if you initialize the type directly. eg: let integer = Int() // integer = 0 let string = String() // string = “” let bool = Bool()// bool = false That said, I’m going to -1 this proposal as

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

I believe the reason behind this comes down to the fact that computed values generally won't be used in this way - thus the "computed". var itself isn't a promise that a value is mutable, so much as 'let' is a promise of immutability. If we allowed this, then the compiler must check that each

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md 1. What is your evaluation of the proposal? +1. While I am not qualified on the

Re: [swift-evolution] Optional assignment operator

I’m tentatively supportive of this proposal. I definitely see the use case (assign only if not not nil). Interested to hear the opinions of others here :) -Rod > On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via > swift-evolution wrote: > > Sorry if

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

While on the face of it, you are correct, the goals have changed dramatically, I think you are being unfair. Swift 3 initial scope was determined prior to the input of the Swift Evolution community, just as it was being Open Sourced. As we have explored the language in many discussions, it has

Re: [swift-evolution] Auto Unwrapping Of Optionals

I agree that it's a pain to have to unwrap after this, but this proposal worries me somewhat. I don't think we can safely guarantee that the value is non-null outside a very limited subset of cases, and we're breaking the simple, general and reasonable syntax of Swift for a very minor

Re: [swift-evolution] proposal for a even simpler guard.. => guard!

I’m on the side of the ‘!’ at the moment. I see a lot of heat here going into hatred of the force unwrap operator, as if it should be avoided like the plague. I simply don’t see the need for such absolutism. It’s there for a reason. There are definitely use cases where use of the force unwrap

Re: [swift-evolution] Introduce OrderedSet type

I believe this would fall in line with by Proposal SE-0069: Mutability and Foundation Value Types: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md I notice there is no OrderedSet in this proposal. I find it odd that it doesn’t yet include

Re: [swift-evolution] Auto Unwrapping Of Optionals

there has to be a better way! > > - Tod > > > > From: > <swift-evolution-boun...@swift.org<mailto:swift-evolution-boun...@swift.org>> > on behalf of Rod Brown via swift-evolution > <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> >

Re: [swift-evolution] Auto Unwrapping Of Optionals

day = today ?? NSDate() // self.today changed! >> guard let today = today else { >> assertFailure() >> return // that should never happen >> } >> let timeInterval: NSTimeInterval = today!.timeIntervalSinceNow >> >> This introduces code t

Re: [swift-evolution] Modify optional method semantics for swift

This issue I see here, and one that people seem to often forget in discussions on Swift a Evolution, is that optional methods aren't just used to change a default value. Their existence often actually changes behavior completely. Take for example UITableViewDelegate and its method

Re: [swift-evolution] Modify optional method semantics for swift

Response inline > On 10 May 2016, at 8:28 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The problem then becomes how do we model suc

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

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md > > > Reply text > >> What is your evaluation of the proposal? > +1 to all except

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Agreed. I think you bring up points that articulate well my issues with this proposal. > On 7 May 2016, at 10:31 AM, Greg Parker via swift-evolution > wrote: > > >> On May 3, 2016, at 8:53 PM, Chris Lattner via swift-evolution >> wrote:

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

I am definitely +1 to this proposal direction I was in the crowd thinking "don't drop the NS on types that should be value types" but I think you make fair points that there can be planned optimizations in the future, and we should focus on getting a good set of naming rules in place. You make

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

ors rather than simply Fix them seems rather odd to me. > > Sent from my iPhone > >> On 12 Jul 2016, at 09:10, Rod Brown via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> After all… you clearly don’t know about your current state, so how ca

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

* What is your evaluation of the proposal? +1. It's consistent with the new language guidelines, and though 'flatten' seemed a term-of-art there are multiple arguments here that would clear up things, like the string combination. * Is the problem being addressed significant enough to

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md - What is your evaluation of the proposal? +1 to the second proposal, if we were to drop the concept of a final class. I feel like by blocking subclasses in preference to

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

This makes perfect sense why it would perform worse, and I agree this seems like a legitimate place for a special case. > On 29 Jul 2016, at 3:01 AM, John McCall via swift-evolution > wrote: > >> On Jul 28, 2016, at 6:38 AM, Paulo Faria via swift-evolution >>

Re: [swift-evolution] [Review] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

> * What is your evaluation of the proposal? +1. Agree we should deprecate legacy features that we don’t intend to support, to make future transitions easier for users. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I think you missed that I actually agree with all your points. My point was merely regarding “pre-breaking” which I thought wasn’t a relevant term. I think a far more appropriate term is “overly limiting”. We are discussing semantics, nonetheless. I actually support the idea that you should be

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md > * What is your evaluation of the proposal? -1. Extensions appear to me

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Review link:  https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md * What is your evaluation of the proposal? +1 for the implementation. +0.5 for the concept. I think this is a clean interface for what open should be, and am glad at the

Re: [swift-evolution] Class mutation model and value-constrained protocols

I definitely see Dave’s point here. It seems to me we can only get generic to the point at which the semantics change. So methods that don’t have any mutating consequences can be applied to any value such as Structs and Classes, but when the semantic relates to mutation, we can only apply that

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

* What is your evaluation of this proposal? A reluctant +1. I’m reluctant because I actually do love the flexibility in Obj-C to subclass where I feel appropriate, and feel the limitations of this are going to be difficult to get used to. From what I see, however, “final” as a concept makes

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Comments inline (resent to swift evolution) > On 7 Jul. 2016, at 4:28 am, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi there > > From the perspective from many active programmers > that use Swift (not objective C anymore) I am not > very happy by having

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

This is the case with a library. It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. UIKit internally would therefore call directly to the

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

@Jonathan I don’t think that "pre-breaking code" is a good description. You are not breaking anything - you’re just not allowing something that *could* become unsafe. It’s safety first, at the cost of the library user’s flexibility. That said, I actually think you have a good point however

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

> On 11 Jul 2016, at 12:33 PM, Jonathan Hull wrote: > > It is pre-breaking in that it is the exact same code that doesn’t work in > both cases (only in the pre-breaking case, a bunch of other code also doesn’t > work). I know it feels different because it “was never possible”

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Resent for Swift Evolution: With the existence of Swift on the server, dynamically linked, independently distributed frameworks will not be an Apple-only issue - this extends beyond Apple's OS X-based platforms towards how dynamic frameworks link against each other as if they are to be

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I personally agree with most of your assessments. It's why I pushed so hard for "allow subclassing my default" in the first discussion of this point. The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

I only had a passing glance but I'm a fan. > On 11 Jul. 2016, at 6:33 am, Jasdev Singh via swift-evolution > wrote: > > Hey Swift Evolution! > > Drafted up a small proposal that harmonizes the use of static functions and > static function properties in appropriate

Re: [swift-evolution] [Proposal] Sealed classes by default

From my understanding, "Sealed" or whatever we will call it technically provides no actual optimisations. We cannot assume the class is final because something inside the module may have vended a subclass. The issue that "sealed" as a concept fills is that you stop people from subclassing

Re: [swift-evolution] Initializers

in documentation or the object I require as part of initialising the property does not exist until after the initialisation. Rod > On 5 Feb 2017, at 4:04 am, Jean-Daniel <mail...@xenonium.com> wrote: > > >> Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution >> <swif

Re: [swift-evolution] Initializers

Hi Joe, I think this comes back to the idea that a lot of people in the wider Swift community hold that Implicitly Unwrapped Optionals are “bad” and “discouraged", and therefore shouldn’t be used. There seems to have been much pushback on Implicitly Unwrapped Optionals in the Swift 3

Re: [swift-evolution] @NSCopying currently does not affect initializers

I agree that there is an issue here. While I understand that the initialiser avoids the full setter for direct access, I would expect the attribute to mean that the substituted direct access still applied the attribute you marked the API with. I would consider the fact that it doesn't work as

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

I applaud the idea. I too find the (NS)Progress API to be very low quality. It seems a vestige of an earlier time when Cocoa was young and APIs that seem like they should be simple, just... aren't. I would love to see a much better API developed. I'm curious how this idea of developing

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

My 2c: +1 to reverting private to the Swift 2 meaning and deprecating or using fileprivate as an alias for private. As a framework developer I am constantly deciding backward and forwards to go private only to realise that my embracing extensions makes it impossible to allow internal

Re: [swift-evolution] [Review] SE-0153: Compensate for the inconsistency of @NSCopying's behaviour

> What is your evaluation of the proposal? It’s clearly a concern and one that should be addressed. A lot of people have bought up the didSet {} property observers are not called when things are set here, either. This is true, but unlike property observers, these are attributes, and I don’t

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

Charles and Tony, Would it be more appropriate to consider suggesting that the Foundation team to consider adding a method of choosing their “notification granularity”, and avoid KVO notifications until it meets the granularity requirement, or some other way of minimising the reporting period

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

I agree with your assessment that KVO may not be the right tool for this because the binding doesn't allow you to declare which thread you'd like the observation posted on. I suspect this design was supposed to be inline with the patterns of Cocoa, despite the fact that the realities of

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

It's an interesting implementation, from my cursory look. Inspired by the bridging wrappers that the rest of the Swift Overlay uses, and with a massive performance win in Swift-only uses. Awesome! It still holds the fundamental oddities of NSProgress that I find weird. Like "current progress"

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

My concern regarding a new class in the overlay is interoperability. With a lot of things in the Swift Overlay, identity isn't relevant. For example, we turn a lot of Objective-C classes into structs because their identity is not relevant, and they should be copied anyway, so it makes sense to

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On 22 Feb 2017, at 7:43 am, Rod Brown via swift-evolution > <swift-evolution@swift.org> wrote: > > My concern regarding a new class in the overlay is interoperability. > > With a lot of things in the Swift Overlay, identity isn't relevant. For > example, we turn a

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

I think the biggest problem we're going to face with this one is changes to Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in control of the development of new Objective-C features and compatibility because they control the compiler. That said, as a request to

Re: [swift-evolution] Overriding protocol default implementation

I don't believe these two worlds are in conflict at all. We currently have the default only state (without overrides), plus a conflict. We would simply be adding "override" functionality in part to clear the conflict. With POP the idea is that the protocol, in knowing about how it is

Re: [swift-evolution] Overriding protocol default implementation

I agree this is a very... tricky part of Swift, and that many have stated it is expected behaviour. I think this is fundamentally incorrect from a design standpoint with the concept of a protocol as an agreed interface, rather than an agreed implementation. By adding a Protocol Extensions, we

Re: [swift-evolution] Overriding protocol default implementation

I see your point. I think the core issue here is customizability vs safety. Allowing users to perform actions in these functions that change the behaviour of a protocol is potentially dangerous, and therefore Swift as a safe language disallows it. This comes at the cost of being able to

Re: [swift-evolution] Overriding protocol default implementation

Sent from my iPhone > On 11 Feb 2017, at 2:20 pm, Xiaodi Wu wrote: > >> On Fri, Feb 10, 2017 at 6:59 PM, Rod Brown wrote: >> I don't believe these two worlds are in conflict at all. >> >> We currently have the default only state (without

Re: [swift-evolution] Type-annotated throws

>> >> On Fri, Aug 26, 2016 at 5:43 PM, Rod Brown via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> (resent for Swift Evolution) >> >> I’m a big fan of this idea. Currently “throws” seems like a v

Re: [swift-evolution] Type-annotated throws

(resent for Swift Evolution) I’m a big fan of this idea. Currently “throws” seems like a very limited API - you know it’s throwing out something, but you can only hope to guess what that is or create fallbacks. Definitely a big +1 from me. A fallback for compatibility could be “throws” assumes

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

> On 5 Jan 2017, at 11:50 am, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > Here’s a draft proposal to limit inference of @objc to only those places > where we need it for consistency of the semantic model. It’s in the realm of > things that isn’t

Re: [swift-evolution] Enhanced Existentials

> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution > wrote: > > Hello Mailing-list, > > I remember we discussed enhanced existentials heavily during the Swift 3 > timeframe but postponed it. I was wondering if we need to bring back for > discussion during

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1. Your proposal seems to confuse something we already have in the language to handle unwrapping and guarding, to only proceed if the item is non-null: Guard. We already have a keyword and behaviour that you specify in the “guard” behaviour. Additionally, changing “guard” to be “obtain”

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

I’m in agreement that ‘dynamic’ is probably not what you want without a declaration. There are currently some bugs in how dispatch works for overrides in Swift extensions, and I’d like to see any methods that conform to an @objc protocol being given an implicit @objc, but true dynamic? No.

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

> On 30 Dec 2016, at 10:50 am, Freak Show <freaksho...@mac.com> wrote: > > >> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I’m in agreement that ‘dynamic’ is probably not what you want withou

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

I'm not part of the core team, of course, but I like this change in principle. My one concern in this case would be choosing a naming convention for the back port that makes sense both ways. The naming convention you propose ( EnumName_EnumCase) seems inconsistent with the current import of

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

Apart from your seeming distain for Swift, this proposal seems misguided to me, and to ignore some of the recent discussion around named parameters on tuples (which are currently in flux). Each of the types you mention each have clear, specific meanings. The following two are basic type system

Re: [swift-evolution] Move placement of 'throws' statement

I have rarely caught up into these situations - if I end up with multiple types of error, I generally create a wrapper error type. For example, my networking code includes a NetworkError type which encompasses all the errors that can happen within Foundation or my own code. Could we not then

Re: [swift-evolution] Move placement of 'throws' statement

I think the clear middle ground is an approach where you *can* document the type, but let it not be required. Additionally, we can treat that at the calling end as a built time assurance of the type for error that is passed into the standard “catch { }”, and the compiler can also check that

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

There has been a lot of discussion around this design decision. Personally, I’m with you: this should be allowed. Protocol extensions should be defaults, nothing more. The rationale mentioned in Swift Evolution for discouraging this behaviour tends to be that if you conform to the protocol,

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

17 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

[swift-evolution] Specified Protocol Conformances in Subclasses

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 delegate; @end @interface UITableView: UIScrollView @property (weak, nonatomic) id delegate; @end @protocol

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

+1 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution > wrote: > >> >> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution >> > wrote: >> >>> What is your evaluation of the proposal? >>

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On 6 Apr 2017, at 4:39 am, John McCall via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-163: String Revision: Collection Conformance, C Interop, > Transcoding" begins now and runs through next Tuesday, April 11th. The > proposal is

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On 7 Apr 2017, at 9:10 am, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now and runs through April 11, 2017. The proposal is >

Re: [swift-evolution] Enums and Source Compatibility - defaults

Yes, I see your point, and that’s something I didn’t consider. If we allowed extending enums, this would then clearly indicate that “final” means something in the present as well - you cannot add cases. This opens up the can of worms of extending enums, but I think it’s a fair point if we ever

Re: [swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?

14, 2017, at 2:41 PM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Jul 14, 2017, at 2:11 AM, Víctor Pimentel via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-ev

Re: [swift-evolution] Setting expectations on when we move to Discourse

Perhaps there’s just a lot of work to do at the moment that has a higher priority than getting an improved Swift Community Comms method. I can scarcely fathom the amount of work within Apple being done to make sure Swift 4, iOS 11, macOS High Sierra, Xcode 9, and all the other great projects

Re: [swift-evolution] Enforce non-nil assignment to an implicitly unwrapped optional property?

Implicitly unwrapped optionals are often used when the optional system is a little complicated around one of your variables. Some of those times are variables that are nil-resettable (where you set nil, and it internally does something to use that as a reset case) or initialisation issues

Re: [swift-evolution] [Pitch] Scoped @available

This is something I’m dealing with as a framework author as well. I’m stumped coming up with anything better than your latter idea of “outside” even though I’m not really a fan. Either way, I think that deprecating outside makes some sense from a framework developer’s perspective. You may need

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

> On 29 Jun 2017, at 11:18 am, Ben Cohen via swift-evolution > wrote: > > >> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> In the initial example, repeated here in largely

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

Thanks Erica. That looks great. As a side-note, one of the sentences in “The Black Swan Deployment” references a “Mackintosh” - I believe this was supposed to be “Hackintosh”. > On 30 Jun 2017, at 3:20 am, Erica Sadun via swift-evolution > wrote: > > >> On Jun

Re: [swift-evolution] [Concurrency] async/await + actors

Hi Chris, I love what I’ve read so far. I just have one curiosity from my cursory look over the proposal. It seems that in transitioning API to an Async Await system, the completion handler’s type becomes the return type. How would you handle bridging in Foundation API that already has a

Re: [swift-evolution] [Concurrency] async/await + actors

> On 18 Aug 2017, at 9:56 am, Rod Brown via swift-evolution > <swift-evolution@swift.org> wrote: > > > Hi Chris, > > I love what I’ve read so far. I just have one curiosity from my cursory look > over the proposal. > > It seems that in transi

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

> On 2 May 2017, at 2:34 am, John McCall <rjmcc...@apple.com> wrote: > >> >> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I agree that the key problem with t

  1   2   >