Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 4:58 PM, Daniel Duan via swift-evolution > wrote: > > >> On Jan 19, 2017, at 2:29 PM, Joe Groff > > wrote: >> >>> >>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0148 Generic Subscripts

> What is your evaluation of the proposal? Very enthusiastic +1. I have wanted this feature ever since Swift was released and I noticed that it was missing. I think the proposal could be made stronger by including some of the examples that were shared in the pre-review discussion. Any

Re: [swift-evolution] Removing var keyword in protocol property reqirements

> On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution > wrote: > > >> On Jan 18, 2017, at 8:50 AM, Tony Allevato wrote: >> >> Good point—I hadn't considered the distinction. >> >> Does that mean a future version of Swift might

Re: [swift-evolution] Removing var keyword in protocol property reqirements

> On Jan 18, 2017, at 11:00 AM, Joe Groff wrote: > >> >> On Jan 18, 2017, at 8:57 AM, Matthew Johnson wrote: >> >> >>> On Jan 18, 2017, at 10:54 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Jan 18,

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

+1. Nesting protocols inside an “owning" type and importing prefixed Objective-C protocols this way would be great! > On Jan 17, 2017, at 6:15 PM, T.J. Usiyan via swift-evolution > wrote: > > +1 to all of that. The proposal in general and the import rule. > > On

Re: [swift-evolution] Generic Subscripts

Sent from my iPad > On Jan 14, 2017, at 12:17 PM, Shawn Erickson via swift-evolution > wrote: > > I have a throwing style data marshaling layer that uses throwing and return > type inference to make the code clean and validation automatic with the > optional

Re: [swift-evolution] Generic Subscripts

Thanks for putting this together! I’m looking forward to seeing this make it into the language! > On Jan 12, 2017, at 11:53 AM, Chris Eidhof via swift-evolution > wrote: > > Ok, I've got a draft up as a gist: >

Re: [swift-evolution] Generic Subscripts

> On Jan 11, 2017, at 12:32 PM, Erica Sadun via swift-evolution > wrote: > > >> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution >> > wrote: >> >> On Jan 10, 2017, at 11:40 AM, Douglas

Re: [swift-evolution] "with" operator a la O'Caml?

> On Dec 22, 2016, at 4:54 AM, Jeremy Pereira > wrote: > >> >> On 21 Dec 2016, at 14:07, Matthew Johnson wrote: >> The performance hit is likely a bit larger if you *don't* use a mutable property and instead create a

Re: [swift-evolution] "with" operator a la O'Caml?

> On Dec 21, 2016, at 4:34 AM, Jeremy Pereira > wrote: > >> >> On 20 Dec 2016, at 13:10, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 20, 2016, at 4:32 AM, Jeremy Pereira via swift-evolution >>>

Re: [swift-evolution] "with" operator a la O'Caml?

Sent from my iPad > On Dec 20, 2016, at 4:32 AM, Jeremy Pereira via swift-evolution > wrote: > > >> On 20 Dec 2016, at 07:54, Pierre Monod-Broca via swift-evolution >> wrote: >> >> But for a struct to be immutable, you don't need all

Re: [swift-evolution] URL Literals

+1. Tony’s static evaluation idea also crossed my mind when reading this thread. > On Dec 17, 2016, at 10:52 AM, Tony Allevato via swift-evolution > wrote: > > If folks want to go down this path, it: > > * shouldn't require compiler magic > * shouldn't be

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Sent from my iPad On Dec 4, 2016, at 4:31 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Dec 3, 2016, at 7:06 PM, Erica Sadun wrote: >> >> A majority of respondents prefer that argument names always be mentioned, >> whether or not

Re: [swift-evolution] [pitch] Implementation composition

> On Nov 25, 2016, at 12:06 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Protocol forwarding was discussed on-list near the end of 2015 in the thread > “[swift-evolution] [Proposal Draft] automatic protocol forwarding”. Feedback > was generally

Re: [swift-evolution] [Review extended] SE-0143: Conditional Conformances

> On Nov 11, 2016, at 1:53 PM, Hooman Mehr via swift-evolution > wrote: > > +1. > > This is the best we can do for now, given time and resources. Agree. There will still be frustrating limitations at times, but this is a huge step forward. > >> On Nov 9, 2016,

Re: [swift-evolution] [swift-dev] Pure Cocoa NSNumbers and AnyHashable

> On Nov 10, 2016, at 2:41 PM, Joe Groff wrote: > >> >> On Nov 10, 2016, at 11:51 AM, Matthew Johnson > > wrote: >> >>> >>> On Nov 10, 2016, at 1:44 PM, Joe Groff >> >

Re: [swift-evolution] [swift-dev] Pure Cocoa NSNumbers and AnyHashable

> On Nov 10, 2016, at 1:44 PM, Joe Groff wrote: > >> >> On Nov 10, 2016, at 11:42 AM, Matthew Johnson wrote: >> >> >>> On Nov 10, 2016, at 1:34 PM, Joe Groff via swift-dev >>> wrote: >>> >>> On Nov 10, 2016, at 10:30

Re: [swift-evolution] guard let x = x

> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution > wrote: > > For what it’s worth, I concur. I think type narrowing makes it feel more like > the language is actually doing some work *for* me rather than me having to > babysit the language with some new

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

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

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

> > > IMO, the best argument against using unicode symbols for operators defined by > mathematics is that they are currently difficult to type. > > And there is no realistic hope of that changing. This issue is so compelling > that C and C++ introduced standardized text-ascii alternatives for

Re: [swift-evolution] [pitch] make @nonobjc the default

> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution > wrote: > > >> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Oct 19, 2016, at 4:53 AM, Jay

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

> On Oct 19, 2016, at 12:27 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Oct 19, 2016, at 7:41 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I very much support the proposal to rationalize our hand

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

I very much support the proposal to rationalize our handling of identifier characters. I also support doing something similar for operator symbols. However, I agree feedback from others that this proposal goes way to far in removing our ability to use mathematical operators. If I’m

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> * What is your evaluation of the proposal? -1. I don’t like the idea of a user-defined `$` identifier. I agree with the reasons for removing it. If it is allowed as a user-defined entity it feels an operator is more appropriate. Otherwise, it could be reserved as a special,

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

Looks very nice. +1 here as well. > On Oct 11, 2016, at 4:28 PM, Nate Cook via swift-evolution > wrote: > > Introduction > > This proposal addresses significant unexpected performance gaps when using > dictionaries. It introduces type-specific collections for a

Re: [swift-evolution] Automatic generation of initializer including default values

We considered a proposal I wrote early in the year. There was extensive discussion of the topic at that time. The core team decided to defer the topic at the time. Everyone was convinced there are better ways to handle it than I originally proposed (including myself). The topic will be

Re: [swift-evolution] private & fileprivate

Sent from my iPad > On Oct 8, 2016, at 5:58 PM, Xiaodi Wu wrote: > > Very much agree with essentially all of that. > > Personally, I'd also want to explore whether any submodule scope could just > subsume fileprivate (i.e., files not otherwise in a submodule behave as

Re: [swift-evolution] private & fileprivate

> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > > wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On Oct 3, 2016, at 8:03 PM, Joe Groff via swift-evolution > wrote: > > >> On Oct 3, 2016, at 9:39 AM, Robert Widmann via swift-evolution >> wrote: >> >> -1 in general. I want smarter exhaustiveness analysis, but I don’t want to >>

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

I agree with previous commenters. I very much support improved exhaustiveness analysis reducing the circumstances where a default clause is necessary. But I think requiring it unless the compiler can *prove* you have covered every possibility communicates important information that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0143: Conditional Conformances

> What is your evaluation of the proposal? Huge +1. Conditional conformances are at the very top of the list of frustrating limitations in Swift. Lifting that limitation can’t happen soon enough for me. I have some concern that the restriction on overlapping conformances could continue to

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 30, 2016, at 1:23 AM, Douglas Gregor wrote: > > >> On Sep 28, 2016, at 4:30 PM, Matthew Johnson > > wrote: >> Is the decision on "no-overlapping-conformances” something that’s seen-as set in stone

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

> > What is your evaluation of the proposal? +1. This is a great enhancement that I have wanted ever since Swift was released. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. It allows us to express our intentions much more clearly and concisely. >

Re: [swift-evolution] Pitch: really_is and really_as operators

ustiveness here I would accept that >> solution. But it seems like an exact match cast operator would be much more >> elegant. >> >> In any case, anything that requires matching every type in a hierarchy >> without being subject to case ordering bugs and doesn’t r

Re: [swift-evolution] Pitch: really_is and really_as operators

at is the problem I would like to see solved. > > > On Thu, Aug 25, 2016 at 08:40 Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: >> On Aug 24, 2016, at 9:33 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gm

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 9:33 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Aug 24, 2016, at 9:09 PM, Robert

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution > wrote: > > I have 3 qualms with this proposal as it stands: > > - type(of:) will never lie to you. > > The only question it won’t answer to your satisfaction is the dynamic type of > the NSString

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

+1. This is fantastic. > On Aug 23, 2016, at 5:36 PM, Douglas Gregor via swift-evolution > wrote: > > Introduction > > A handful of Swift numeric types are bridged to NSNumber when passed into > Objective-C object contexts. We should extend this bridging behavior

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On Aug 20, 2016, at 1:29 PM, Xiaodi Wu wrote: > > That's good information. I guess a partly implied question which I'm not > entirely sure of would be: > > What are the scenarios you've encountered where it actually matters that an > algorithm that works with any P & Q

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On Aug 20, 2016, at 12:27 PM, Xiaodi Wu wrote: > > Maybe I'm not getting something. But if you only want T | U | V to expose > members required by common protocols P, Q, and R, since you know the types at > compile time, you also know the common protocols. Why wouldn't

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On Aug 20, 2016, at 10:36 AM, Haravikk wrote: > > >> On 19 Aug 2016, at 15:38, Xiaodi Wu via swift-evolution >> wrote: >> >> Ad-hoc enums have been discussed already, at length, and all the weaknesses >> touched on then still apply

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

`enum FooOrBar` just obscures the intent). > > In any case, this all seems very, very out of scope for Swift 4. I agree with this, certainly for phase 1 in any case. I don’t want to push a distracting discussion right now. I just wanted to respond to Brent with my thoughts. > > &

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On Aug 19, 2016, at 1:20 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 18, 2016, at 2:05 AM, Maximilian Hünenberger via swift-evolution >> wrote: >> >> While purpose of the types are clear in this case there is not

Re: [swift-evolution] Improved value and move semantics

> On Aug 4, 2016, at 9:39 AM, Joe Groff wrote: > >> >> On Aug 3, 2016, at 8:46 PM, Chris Lattner wrote: >> >> On Aug 3, 2016, at 7:57 PM, Joe Groff wrote: >> >> a. We indirect automatically based on some heuristic, as an

Re: [swift-evolution] Improved value and move semantics

> On Aug 3, 2016, at 3:48 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Aug 03 2016, Matthew Johnson wrote: > >>> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Improved value and move semantics

> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Aug 02 2016, Brent Royal-Gordon wrote: > >>> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> If it says that,

Re: [swift-evolution] [Idea] Generic subscripts

> On Aug 3, 2016, at 4:16 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 3, 2016, at 1:57 AM, Tino Heth <2...@gmx.de> wrote: >> >>> Since RangeExpression is a protocol compatible with any index type, it has >>> to have an associated type >> I

Re: [swift-evolution] [Idea] Generic subscripts

> On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution > wrote: > > I'm looking for consensus on, and a coalition for, including generic > subscripts in Phase 1 of the Swift 4 design cycle. > > The Need > - > > While prototyping my

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 8:47 PM, Brent Royal-Gordon > wrote: > >> On Jul 27, 2016, at 6:43 PM, Matthew Johnson wrote: >> >>> In a future version of Swift, we might consider refining this by requiring >>> people to apply `@testable` directly to

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

> On Jul 27, 2016, at 8:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution >> wrote: >> >> I brought this up in review, but there seems to be a serious testability

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 25, 2016, at 3:22 PM, Nate Cook via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md > > First, a big thanks to Brent for all the work in categorizing, describing, > and

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

> On Jul 25, 2016, at 6:38 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > Of the designs

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> > * What is your evaluation of the proposal? I was not totally happy with early drafts of this proposal. The final draft is a significant improvement. I am mostly +1, with a couple of minor critiques. I think this proposal pushes a bit too hard on consistency of “first / last” vs

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

; >>> >>> on Fri Jul 22 2016, Xiaodi Wu wrote: >>> >>>> On Fri, Jul 22, 2016 at 9:23 PM, Matthew Johnson <matt...@anandabits.com >>>> >>>> wrote: >>>> >>>>> >>>>> On Jul 22, 2016, at 9:17 PM, Xiaod

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

Jul 22, 2016, at 9:17 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>>> >>>> On Jul 22, 2016, at 9:04 PM,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Fri, Jul 22, 2016 at 9:15 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 22, 2016, at 9:04 PM, Dave

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:15 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:13 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:10 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:24 PM, Dave Abrahams wrote: > > > on Fri Jul 22 2016, Matthew Johnson wrote: > >>> On Jul 22, 2016, at 9:04 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Fri Jul 22 2016, Matthew Johnson

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:20 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 9:19 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 9:12 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:04 PM, Xiaodi Wu wrote: > > On Fri, Jul 22, 2016 at 8:57 PM, Matthew Johnson > wrote: > >> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:54 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:52 PM, Jaden Geller via swift-evolution > > wrote: > "The totalOrder predicate will order these cases,

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 8:43 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jul 22, 2016 at 8:42 PM, Jaden Geller > wrote: >> For floating point, I'd hope that `a === b` if `(a <=> b) == .same` *but not

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 5:50 PM, Stephen Canon <sca...@apple.com> wrote: > >> On Jul 22, 2016, at 6:34 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Sorry if it wasn’t c

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

om >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Fri, Jul 22, 2016 at 5:17 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 22, 2016, at 4:47 PM, Dave

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 4:47 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jul 22 2016, Tony Allevato > wrote: > >> I like a lot of this, but the changes to Equatable are where I get stuck.

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

> On Jul 22, 2016, at 9:48 AM, Karl via swift-evolution > wrote: > > >> On 22 Jul 2016, at 03:32, Robert Widmann via swift-evolution >> > wrote: >> >> >>> On Jul 21, 2016, at 6:19 PM, Xiaodi Wu

Re: [swift-evolution] Returning nothing

> On Jul 21, 2016, at 12:51 PM, Haravikk <swift-evolut...@haravikk.me> wrote: > > >> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >>> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolut

Re: [swift-evolution] Returning nothing

u, Jul 21, 2016 at 11:52 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution > > <s

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

> * What is your evaluation of the proposal? +1 to the first design. I think this is a great solution that balances the many considerations that have been raised on all sides of this issue. `open` is 2 characters shorter than `public` so complaints about boilerplate are no longer

Re: [swift-evolution] Returning nothing

Sent from my iPad > On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution > wrote: > > This may be a silly question - given that one of Swift’s design principles is > to be a language for new programmers and for APIs to read like English > phrases,

Re: [swift-evolution] [Pitch] Memberwise initialisers adopt the same access modifiers as the struct

Sent from my iPad > On Jul 21, 2016, at 11:26 AM, Ian Keen wrote: > > I did see that one, however it appeared that proposal didn’t could on the > access of the initialiser itself at all? just how it interacts with different > properties access levels. It was kinda

Re: [swift-evolution] [Pitch] Memberwise initialisers adopt the same access modifiers as the struct

> On Jul 20, 2016, at 8:15 PM, Ian Keen via swift-evolution > wrote: > > Not much to this one… I think the memberwise `init` should follow the same > level of access as the struct. It appears to default to `internal` regardless > of the struct access modifiers >

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

> On Jul 21, 2016, at 3:13 AM, Tino Heth via swift-evolution > wrote: > > >> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution >> : >> >> A class that is closed in 1.0 can be opened in 1.1; a class that is `final` >>

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

Sent from my iPad On Jul 20, 2016, at 8:47 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 20, 2016, at 12:58 PM, Garth Snyder via swift-evolution >> wrote: >> >> However, the current notation of -> Type being used to

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution > wrote: > > Yes, sorry, my point was that this consideration isn't spelled out. > > Another question is whether or not making a subclass of an open class public > by default is

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

> On Jul 11, 2016, at 1:49 PM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose > wrote: >> P.S. There’s also an argument to be made for public-but-not-conformable >>

Re: [swift-evolution] [Pitch] Extending Swift Literals

Sent from my iPad > On Jul 11, 2016, at 1:11 AM, Charlie Monroe via swift-evolution > wrote: > > Several notes: > > - SKColor is a typealias for NS/UIColor. > - There are other colorspaces beyond RGB. Within such a redesign, I'd > personally vote for adding HSB,

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

Sent from my iPad > On Jul 10, 2016, at 10:38 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > (This is my second response to this

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

> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote: > > >> Of course it can be done either way. But there are significant ecosystem >> robustness advantages to making sealed the default and comparatively few >> downsides. Most libraries are open source (so can be modified directly

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

dig them up right now. > > I’m genuinely curious, since Im still on the fence about this, but am willing > to be convinced… if sealed by default brings more positives than negatives… > > Thanks in advance. > > Andre > > >> 2016/07/09 21:36、Matthew Johnson via sw

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

al-world scenario would "not end well" cover? >>> >>> I’m genuinely curious, since Im still on the fence about this, but am >>> willing to be convinced… if sealed by default brings more positives than >>> negatives… >>> >>&

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

Sent from my iPad > On Jul 9, 2016, at 8:31 AM, Goffredo Marocchi wrote: > > Ok, then I should ask you to consider what I said earlier and substitute > "final by default" with "sealed by default" and if we have this sealed > keyword not to make it the default. > Trust

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

Sent from my iPad > On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > >> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution >> wrote: >> >> Even in Java, it is a bad idea

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

The stories I’ve seen about things Apple’s frameworks need to deal with are another. I don’t have links handy but they shouldn’t be too hard to find for anyone interested in looking. > On Jul 8, 2016, at 4:21 PM, Leonardo Pessoa wrote: > > I've sent one I currently have

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

Sent from my iPad > On Jul 8, 2016, at 12:30 PM, Tino Heth <2...@gmx.de> wrote: > > >> 1. As you point out, the majority of the surface area of idiomatic Swift >> APIs are unlikely to be impacted (value types, protocols, and final >> classes). This is very likely to apply to future

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

>>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson <matt...@anandabits.com>: >>>> >>>> >>>> >>>> Sent from my iPad >>>> >>>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz <tseit...@icloud.com> w

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

n Jul 8, 2016, at 8:48 AM, Thorsten Seitz <tseit...@icloud.com> wrote: >>> >>> >>> >>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org>: >>>> >>>> >>

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

Sent from my iPad > On Jul 8, 2016, at 8:48 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > >> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org>: >> >> >> >> Sent from

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

Sent from my iPad > On Jul 7, 2016, at 5:15 PM, John McCall via swift-evolution > wrote: > > n Jul 7, 2016, at 9:39 AM, Goffredo Marocchi via swift-evolution > wrote: >> I disagree that a stable for over 30 years of every OOP language

Re: [swift-evolution] [Review #2] SE-0091: Improving operator requirements in protocols

> * What is your evaluation of the proposal? +1. This proposal improves clarity by allowing operator implementations to be declared inside the relevant type (or an extension of it). It also improves implementation as outlined in the proposal. Both are significant steps forward. >

Re: [swift-evolution] Separating the finite-vs-infinite distinction from single-vs-multi-pass

Sent from my iPad > On Jul 6, 2016, at 6:50 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jul 06 2016, Dave Abrahams wrote: >> >> Finally, as mentioned earlier we could easily supply a protocol that >> makes it no harder than conforming to

Re: [swift-evolution] Dropping Comparable requirement for indices

Sent from my iPad > On Jul 6, 2016, at 7:33 PM, Xiaodi Wu via swift-evolution > wrote: > > I for one would be interested in your elaboration. Based on Dave's comments, > I'm pretty convinced that the Comparable requirement is best left in place. +1 >> On Wed,

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

Sent from my iPad > On Jul 6, 2016, at 6:47 PM, Scott James Remnant wrote: > > >>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >>> >>> To give you an example of the confusion, here is code made perfectly legal >>> by SE-0025: >>> >>>

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

Sent from my iPad > On Jul 6, 2016, at 6:39 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >> >> Many of us believe “final” is too blunt a tool. There are many cases where >> final cannot be used but

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

> On Jul 6, 2016, at 5:13 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 2:47 PM, Matthew Johnson > > wrote: >> >> This is not true. Public classes will *not* be “final by default”. It >> *will* be

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

> On Jul 6, 2016, at 4:36 PM, Scott James Remnant via swift-evolution > wrote: > > >> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa > > wrote: >> >> You can also try and simplify your outlines reducing X.c and X.d to a

Re: [swift-evolution] Dropping Comparable requirement for indices

Sent from my iPad > On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution > wrote: > > > I've already raised the question here of whether we should weaken the > requirement that Collection.Index be Comparable to merely being > Equatable. > > Part of the

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

Sent from my iPad > On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution > wrote: > > Huge +1. > > Question about inheritance though: > > class A {} // Not publicly subclassable > subclassable class B: A {} // Publicly subclassable > class C: B {} //

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

Sent from my iPad > On Jul 5, 2016, at 8:53 PM, John McCall via swift-evolution > wrote: > > >>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>>* What is your evaluation of the proposal? >>

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

Extremely strong +1 from me on this proposal. It is the best default for many, many reasons (stated in the proposal and in Austin's review). It improves safety, facilitates and encourages reasoning about code, and will result in an ecosystem of overall higher quality. Sent from my iPad > On

<    2   3   4   5   6   7   8   9   10   11   >