Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

> What is your evaluation of the proposal? +1 to the idea. Disappointing that we don’t seem to be able to add this to @objc enums. Could we come up with some kind of workaround for this? > Is the problem being addressed significant enough to warrant a change to > Swift? Yes, this is a common

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

I think you make a fair point here - either case is currently untestable in a non-exhaustive enum. Perhaps this pushes harder on the “future” case and a way we can test this in Unit Tests when we @testable import other frameworks to simulate an additional case. > On 22 Dec 2017, at 5:36 am,

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for this response, John. I think you’re right. This would be very helpful. It a) helps those who are source compiling with their app, and b) avoids fragmenting the language because it would be a core understanding of the code you are compiling, rather than creating a new “variant” of

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

Thanks for this reply, Chris. It addresses most of my concerns with the current design - scalability (with the attributes), confusion (over the meaning of ABI) and changes in declarations as things change. I think your approach is a far better solution. > On 21 Dec 2017, at 6:14 pm, Chris

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On 20 Dec 2017, at 9:58 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018. > > The proposal is available here: > >

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On 17 Nov 2017, at 9:23 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE-0190 - Target environment platform condition" begins now > and runs through November 24, 2017. > > The proposal is available here: > >

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

> On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution > wrote: > > Hi Florent, > > We definitely thought about this while designing the set of types with the > Codable proposals. > > One serious concern was just how much API surface area there already is

Re: [swift-evolution] JSONEncoder: Key strategies

I’m a fan. I understand that the CodingKey was the initial thought behind how to customise this, but a transformative approach is nice where there is a patterned update to keys. Just one question: is there much performance impact by running through a key encoding strategy, even if it’s just a

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

> On 30 Oct 2017, at 6:16 am, Ted Kremenek via swift-evolution > wrote: > > A complementary tactic would be that migration tool support to Swift 5 would > insert the needed casts to NSString. That way even if the magic lookup is > gone in Swift 5 the code could be

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Kevin, I really like your reasoning about avoiding the code churn, and finding a better way to flag something to avoid optional hoisting. I think its better solution to the problem. It also has the added benefit of kicking out to map() and getting a slightly optimised version of the same

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

Hi Jon, An interesting proposal. I see value in an external markdown-formatted document to compliment our Swift code, but currently I already do this when discussing ideas or architecture and just call it “.md”. I agree with Erica on the point though that documentation with code is actually

Re: [swift-evolution] Adding Result to the Standard Library

I was thinking the same thing. Typed throws vs `Error` throws are the two major differences between different Result implementations, and they seem somewhat tied from a discussion perspective. I agree with others here, I would like to see this added to the library, and I think it’s a generally

Re: [swift-evolution] Enums and Source Compatibility

> On 18 Sep 2017, at 9:46 am, Christopher Kornher wrote: > > >> On Sep 17, 2017, at 5:04 PM, BJ Homer > > wrote: >> >> Please note that, as proposed, enums are always treated as exhaustive >> *within the same module*. A new user

Re: [swift-evolution] Enums and Source Compatibility

> On 17 Sep 2017, at 4:35 am, Christopher Kornher wrote: > >> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution >> > wrote: >> >> If a library writer can’t remember to declare non-exhaustive

Re: [swift-evolution] Enums and Source Compatibility

> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution > wrote: > > I am still unsure why we are choosing again a default that protects library > writers more than library users where it is reasonable to expect the former > to have better mastery of

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, I think this is a great update to the proposal. The scope is small, which is good, and it clearly speaks about it’s reasoning about some of the concerns some people have. A big thumbs up from me!  - Rod > On 14 Sep 2017, at 5:16 am, Jordan Rose via swift-evolution >

Re: [swift-evolution] Enums and Source Compatibility

Jordan, Do you have any other thoughts about the ongoing discussion here, especially regarding Chris’ comments? As you’re the one pushing this forward, I’d really like to know what your thoughts are regarding this? - Rod ___ swift-evolution mailing

Re: [swift-evolution] Enums and Source Compatibility

> On 8 Sep 2017, at 2:55 am, Vladimir.S wrote: > > On 07.09.2017 18:23, Rod Brown wrote: >> >> This was discussed earlier. As I mentioned, we should be realistic: it’s >> rarely a >> truly fatal error when you get an unknown enum. Unless you really can’t find >> a >>

Re: [swift-evolution] Enums and Source Compatibility

> On 8 Sep 2017, at 12:24 am, Vladimir.S wrote: > > > > On 07.09.2017 16:03, Rod Brown wrote: >>> On 7 Sep 2017, at 9:26 pm, Vladimir.S via swift-evolution >>> > wrote: >>> Just small note. As I understand, this

Re: [swift-evolution] Enums and Source Compatibility

> On 7 Sep 2017, at 9:26 pm, Vladimir.S via swift-evolution > wrote: > > On 07.09.2017 7:33, Chris Lattner via swift-evolution wrote: >>> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution >>> >

Re: [swift-evolution] Enums and Source Compatibility

> On 7 Sep 2017, at 2:33 pm, Chris Lattner via swift-evolution > wrote: > > >> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution >> > wrote: >> >> I've taken everyone's feedback into

Re: [swift-evolution] Enums and Source Compatibility

Hi Brent, Thanks for the analysis of the issues here. I think you’re right that there are two major types of enums, and that there are a set developers tend to switch on that are usually fixed, where additional cases won’t make sense. I think there are several issues that I see with these

Re: [swift-evolution] Enums and Source Compatibility

>> I see the logic of this position, but it traps at cases which are unforeseen >> unrelated to OS releases. As this proposal notes, there are cases that Apple >> uses internal of their frameworks that they consider private may still be >> passed through your API. >> >> For example, if there

Re: [swift-evolution] Enums and Source Compatibility

> On 6 Sep 2017, at 4:35 pm, David Hart wrote: > > Hi Jordan, > > I like this new direction. But I have Rod’s inverse question: have you > considered only having the nonexhaustive keyword? Similar to how non-final > doesn't exist because its opposite is the default

Re: [swift-evolution] Enums and Source Compatibility

> On 6 Sep 2017, at 2:31 pm, Charlie Monroe <char...@charliemonroe.net> wrote: >> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I think what you’re really asking

Re: [swift-evolution] Enums and Source Compatibility

, but this will then show up in documentation changes, header updates etc, and as you’ve mentioned, it will avoid confusion. Sorry! I think I just needed some time to roll it around my head a bit haha - Rod > On 6 Sep 2017, at 10:47 am, Rod Brown via swift-evolution > <swift-evolution@swift.o

Re: [swift-evolution] Enums and Source Compatibility

Ah yes, my eye skipped that alternative for some reason! Sorry. I’d be concerned that avoiding a default is a fix for a compatibility problem, not a language design decision. If we look back in 5 years and say “why do we need to keep writing nonexhaustive everywhere?”, we’ll have to say “there

[swift-evolution] Re: Enums and Source Compatibility

Hi Jordan, I’m not sure how much bearing on this my comment will have. Have you considered having only “exhaustive” as a keyword, and make the default non-exhaustive? It seems that “exhaustive" would be the rarer case, as it promises a lot more about compatibility (much like there is no such

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] [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] 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] [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] 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] 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] [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] [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] Yet another fixed-size array spitball session

While I can’t comment about the technical details, I have to say, this looks really “unswifty” to my eye. I’d probably expect something more along the lines of: let x: FixedArray = [1, 2, 3] or: let y: StaticArray = [1, 2, 3] > On 29 May 2017, at 4:37 pm, Daryle Walker

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

> On 2 May 2017, at 2:33 pm, Xiaodi Wu via swift-evolution > wrote: > > On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan > wrote: > Xi: "Does this gain something by being part of the standard library?" > Me: "This

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

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

> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan wrote: > > Yeah, you’re absolutely right. the “value-or-nil” and > “value-or-reason-why-not-value” are two different things and the former is > used too liberally in place of the latter because of lack of support. > In that

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

The problem I see with your argument is that the core reason why the optional cast failed is actually there: It was an optional value, and you forced it to unwrap without checking. This is a correct description of the error. If we plumbed our code with a tonne of errors saying “why this is

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

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

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

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

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

> 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

@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

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

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

  1   2   >