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

Is it more unreasonable to ask developers to seal their modules or users to unseal them? I would say Apple or third parties shipping frameworks could be asked to think about subclass ability before shipping their commercial library. Sent from my iPhone > On 11 Jul 2016, at 07:36, Rod Brown via

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

Interesting example but it only explain that a sealed keyword is needed (which I agree), and not why sealed should be the default (which I disagree). > Le 10 juil. 2016 à 21:18, Leonardo Pessoa a écrit : > > Should I assume then you want so much this proposal to be dropped you didn't > even mi

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

Wouldn't that be served better by `case let (x?, y?) where validate(x) && validate(y)` ? Jacob On Sun, Jul 10, 2016 at 11:39 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > Or, less contrived, based on code I just wrote today (and refactored, > because this doesn't work t

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

On Mon, Jul 11, 2016 at 1:41 AM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > The existing literals are both few and pretty foundational to programming, > so I don't mind them being slightly "magical". Rather than introducing > another dozen "magic" types, wouldn't it be

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

The existing literals are both few and pretty foundational to programming, so I don't mind them being slightly "magical". Rather than introducing another dozen "magic" types, wouldn't it be better to allow custom literal types, and have all these types use that system? - Dave Sweeris > On Jul

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

Or, less contrived, based on code I just wrote today (and refactored, because this doesn't work today), given two optionals a and b: ``` let c: Foo? switch (a, b) { case let (x?, y?): if validate(x) && validate(y) { c = x & y // yes, bitwise and continue } fallthrough case let (x?, n

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 distribu

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

On Mon, Jul 11, 2016 at 1:16 AM, David Owens II via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 10, 2016, at 10:53 PM, Austin Zheng wrote: > > > On Jul 10, 2016, at 10:30 PM, David Owens II wrote: > > > I wish the core team or the author of the proposal came to this thread and

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 11:16 PM, David Owens II wrote: > > Unless you really want to try and get parameter name syntax changed to match > your example: > > func doResizeB(image: Image, completed(original:resized:): (Image, Image) -> > Void) This is what I had in mind. You would be able to nam

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 11:09 PM, Mark Lacey wrote: > > In the meantime one option here would be to define a nested function that > invokes the callback. It results in boilerplate, which is unfortunate, but > would work: > > func doResize > ( > image: Image, > completed completedParam: (ori

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

Right. I think if these things turn out to be sufficiently universal, I'd want full canonical types and not just literals from Swift. I'm satisfied that there's now a first-class URL value type provided by Foundation, for instance, and there I fail to see what I would gain with a "URL literal" tha

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 10:53 PM, Austin Zheng wrote: > > >> On Jul 10, 2016, at 10:30 PM, David Owens II > > wrote: I wish the core team or the author of the proposal came to this thread and engaged again with the community. >>> >>> I'm not inclined to

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

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, CMYK, Grayscale. - NSPoint is just a typealias for CGPoint, just like NSRect is CGRect, etc. - there is really no type inferring since it'

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

switch fourSidedShape { case rhombus: // do some rhombus-specific work if parallelogram ~= shape { continue } // do some other rhombus-specific but parallelogram-inapplicable work fallthrough case rhomboid: // do work the slow way // applies to all rhomboids including rhombuses unless parallelogram

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 10:53 PM, Austin Zheng via swift-evolution > wrote: > > >> On Jul 10, 2016, at 10:30 PM, David Owens II > > wrote: I wish the core team or the author of the proposal came to this thread and engaged again with the community. >>> >

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

This is a great feature, and this is something that would allow the execution of multiple case statements that fallthrough does not currently allow. For example in today's world this is not allowed: func blah(point: CGPoint) { switch (point.x, point.y) { case (let x, _) where x > 10:

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

I'm going to argue that these things are universal, just as applicable to Linux/Windows/etc platforms as they are to the Cocoasphere. -- E > On Jul 11, 2016, at 12:01 AM, Xiaodi Wu wrote: > > Ah. Now I see the use case. I'd counter, however, that these are weaknesses > of the respective fram

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

Ah. Now I see the use case. I'd counter, however, that these are weaknesses of the respective frameworks, and that literals as you propose them are rather like a thin version (in the motivating problem it's trying to solve) of the longed-for UXKit that'll supposedly unify all. Even if we have thes

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 11:54 PM, Xiaodi Wu wrote: > > I disagree. First, in both cases there's an A and a B. The two scenarios we > are comparing are "if condition continue, else break" and "if condition > continue, else fallthrough". Both break and fallthrough are equally control > transfer e

Re: [swift-evolution] Change subscripts to use colons

On Sun, Jul 10, 2016 at 10:42 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 10, 2016, at 5:18 PM, James Froggatt via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Currently, the signature is: > > subscript(_ example: Int) -> Element { > >get

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I disagree. First, in both cases there's an A and a B. The two scenarios we are comparing are "if condition continue, else break" and "if condition continue, else fallthrough". Both break and fallthrough are equally control transfer experiments. Both of these scenarios add complexity for reasoning

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

On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution wrote: > > I share the concern with others about the usefulness of these, but I also > like your note about standardizing syntax, and really like that these merge > together all the different syntaxes for literals we've seen. Li

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 10, 2016, at 10:30 PM, David Owens II wrote: >>> >>> I wish the core team or the author of the proposal came to this thread and >>> engaged again with the community. >> >> I'm not inclined to spend time engaging with people who couldn't be bothered >> to give feedback during the wee

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu wrote: > > Right. Both seem equally reasonable alternatives if a condition isn't > fulfilled where I'd like to continue pattern matching. Why do you say one of > these would be fair to disallow? I'm saying pick behavior A or behavior B but don't do A

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

> 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. Your argument is true, and you choose a good example — but it's actually the only one

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

I share the concern with others about the usefulness of these, but I also like your note about standardizing syntax, and really like that these merge together all the different syntaxes for literals we've seen. To that end, I'd like to modestly suggest that #literal.foo (as already written in the

Re: [swift-evolution] Change subscripts to use colons

> On Jul 10, 2016, at 5:18 PM, James Froggatt via swift-evolution > wrote: > > Currently, the signature is: > subscript(_ example: Int) -> Element { >get { … } >set { … } > } > > The alternative, using a colon, would be: > subscript(_ example: Int) : Element { >get { … } >set {

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

Right. Both seem equally reasonable alternatives if a condition isn't fulfilled where I'd like to continue pattern matching. Why do you say one of these would be fair to disallow? On Mon, Jul 11, 2016 at 00:39 Erica Sadun wrote: > Because one says "consider the next case" and the other says "do n

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

Because one says "consider the next case" and the other says "do not consider the next case" > On Jul 10, 2016, at 11:03 PM, Xiaodi Wu wrote: > > I know how it works. Why would you say that it's reasonable to prohibit > fallthrough when continue is used? The difference between it and break is

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

Not completely sold on this one. First, the literal part is already pretty much implied, and I'd prefer dropping it as it feels too "heavyweight". The other, more serious issue was already partially touched upon by Xiaodi, that a lot of these are basically String representations. The Bezier path

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 9, 2016, at 9:08 AM, Austin Zheng via swift-evolution > wrote: > >> On 9 Jul 2016, at 00:53, Jon Shier > > wrote: >> >>> While I can see why removing the labels from the type system would be a >>> good idea, I don’t see why calling the functions with labels

Re: [swift-evolution] Change subscripts to use colons

+1, seems right to me. The original email wasn't clear to me, but this example is. FWIW, as a user of the language I'd hope that throwing subscript getters/setters would be written "set throws { ... }" and/or "set(newValue) throws { ... }" rather than "throwing set { ... }", for consistency with f

Re: [swift-evolution] Change subscripts to use colons

+1 as well. It always feels a little weird to be writing a setter inside something that says it returns what should be the argument. On Mon, Jul 11, 2016 at 00:05 Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Good point. A subscript basically a parameterized property,

Re: [swift-evolution] Change subscripts to use colons

Good point. A subscript basically a parameterized property, not a function. I'm in favor. On Mon, Jul 11, 2016 at 9:18 AM, James Froggatt via swift-evolution < swift-evolution@swift.org> wrote: > Currently, the signature is: > subscript(_ example: Int) -> Element { > get { … } > set { … }

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I know how it works. Why would you say that it's reasonable to prohibit fallthrough when continue is used? The difference between it and break is that Swift chooses the latter to be implied, and obviously we cannot prohibit break. On Sun, Jul 10, 2016 at 23:51 Erica Sadun wrote: > On Jul 10, 2016

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

Well, in my book, a thing without a representation isn't really a 'literal', which to me implies some degree of WYSIWYG :) On Sun, Jul 10, 2016 at 23:56 Erica Sadun wrote: > > > On Jul 10, 2016, at 10:30 PM, Xiaodi Wu wrote: > > > > Questions/comments-- > > > > What's your use case for these? >

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

> On Jul 10, 2016, at 10:30 PM, Xiaodi Wu wrote: > > Questions/comments-- > > What's your use case for these? > > For proposed literals like `point`, I'm having trouble visualizing how that > could be literally represented. Since the difference between one point and > another is its coordina

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 10:34 PM, Xiaodi Wu wrote: > > > > On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun > wrote: >> On Jul 10, 2016, at 10:16 PM, Xiaodi Wu > > wrote: >> Given patterns A, B, C, and D, suppose a value x matches A, C, and

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

On Sun, Jul 10, 2016 at 10:38 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> 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 proposal. The previous message

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun wrote: > On Jul 10, 2016, at 10:16 PM, Xiaodi Wu wrote: > Given patterns A, B, C, and D, suppose a value x matches A, C, and D, > whereas another value y matches B and D, and a third value matches B and > C. When evaluating x, y, or z, which statemen

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

Questions/comments-- What's your use case for these? For proposed literals like `point`, I'm having trouble visualizing how that could be literally represented. Since the difference between one point and another is its coordinate, would we just see a point floating on the screen? Something like

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 10:16 PM, Xiaodi Wu wrote: > Given patterns A, B, C, and D, suppose a value x matches A, C, and D, whereas > another value y matches B and D, and a third value matches B and C. When > evaluating x, y, or z, which statements are executed in the following switch > statement?

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

On Sun, Jul 10, 2016 at 10:48 PM, Erica Sadun wrote: > > > On Jul 10, 2016, at 8:37 PM, Xiaodi Wu wrote: > > > > This is a neat idea, and I think a very sensible way to extend the > language. I worry only a little about the following: > > > > Currently, unless preceded immediately by the keyword

[swift-evolution] [Pitch] Extending Swift Literals

This is purely additive and would not be eligible for Swift 3. gist: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c -- E Extending Swift Literals Proposal: TBD Author: Erica Sadun Status: TBD Review manager: TBD

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 8:37 PM, Xiaodi Wu wrote: > > This is a neat idea, and I think a very sensible way to extend the language. > I worry only a little about the following: > > Currently, unless preceded immediately by the keyword `fallthrough`, a > condition implicitly excludes all previous

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 8:36 PM, Taras Zakharko wrote: > > There is possible impact on existing code: a switch statement inside a loop, > that contains a continue. > > — Taras A switch statement within a loop may be broken by the introduction of `continue` semantics. To fix, the loop must be

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ] (This is my second response to this proposal. The previous message shared a use case where public-but-non-subclassable made things work out much better with required initializ

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

Well stated and has pushed me into favoring the closed be default case. I favor being explicit and the default being safe (you can always unseal in a future revision if a need arises). Also as you note it won't prevent bad implementations but it will help library developers better bound their exte

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

> On Jul 10, 2016, at 9:53 PM, Paul Cantrell via swift-evolution > wrote: > > >> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution >> wrote: >> >> 2. The motivation seems to be that it will force better API design. > > No, that wasn’t my motivation in giving it a +1. This seems t

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

> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution > wrote: > > 2. The motivation seems to be that it will force better API design. No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll address it. Accepting this prop

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” vs our > change

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

This is a neat idea, and I think a very sensible way to extend the language. I worry only a little about the following: Currently, unless preceded immediately by the keyword `fallthrough`, a condition implicitly excludes all previous conditions. That is, if I write `switch .. { case a: ...; case b

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is possible impact on existing code: a switch statement inside a loop, that contains a continue. — Taras > On 11 Jul 2016, at 04:27, Erica Sadun via swift-evolution > wrote: > > A quick pitch to introduce `continue` to switch statements. This would be > additive and could not be consi

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

> On Jul 10, 2016, at 6:45 PM, Rod Brown wrote: > > @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.

[swift-evolution] [Pitch] Introduce continue to switch statements

A quick pitch to introduce `continue` to switch statements. This would be additive and could not be considered for Swift 3. -- E Pitch: Introduce continue to Switch Statements Introduction This pitch completes the s

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

Leonardo's example makes the case for why Swift should adopt a 'sealed' keyword that can be used to make public classes non-subclassable outside the module where they are defined, but not for why this should be the default. Others have made these points before, but these are the two biggest reason

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 that

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

>> >>> 2016/07/09 23:30、Matthew Johnson >> > のメール： >>> >>> This leaves the scenario of a case where you depend on a 3rd party, >>> closed-source library written in Swift and where you cannot get (or use) a >>> fix from the vendor for some reason. This is a legiti

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 UINa

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

To highlight your comment below - I would favor “sealed” being available, I’m not sure I would favor it being the default. Would it help to perhaps split this into two proposals. First, decide on the issue of sealable being available first and syntax for it. If this passes then a second proposa

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

> On Jul 9, 2016, at 16:37, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: > >> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He >> was working on a closed class hierarchy like the ones discussed h

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

@Rod: Thank you for actually replying to the content of my post. Much appreciated. It is a trolly problem. You are arguing that pre-breaking everyone's code is better (even if causes way more trouble overall) than taking an action that breaks a few people’s code later (and thus feeling respo

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

> On Jul 9, 2016, at 01:44, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution >> wrote: >> >> Of course, Swift doesn’t allow this. If someone outside of the module >> subclasses ModelBase, there’s no way for them to provide the

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

> On Jul 8, 2016, at 23:47, L. Mihalkovic wrote: > > > > Regards > (From mobile) > > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> [Proposal: >> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-sub

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

I think folks are going in an unprofessional direction in this thread, let bring it back to a more positive direction please. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought. I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now

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

> You asked me to correct you and I shall: Well, in the first place, I asked how many subclasses you have to "seal" manually… may I assume that it is a low number? > You asked for an example where this feature would be needed and I've provided. No, actually you provided an example where you thin

Re: [swift-evolution] Change subscripts to use colons

Currently, the signature is: subscript(_ example: Int) -> Element { get { … } set { … } } The alternative, using a colon, would be: subscript(_ example: Int) : Element { get { … } set { … } } Sorry if that wasn't clear. This would be to better reflect the property-like nature of

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

> 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 non-final. I also > can seal a class which has previously been open to subclassing. Of course you can do both — it may make users angry, but so what? The e

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

IMHO SE-0117 is one of the worst Swift 3 proposals that have ever been proposed. It has the potential to make the language much worse. I haven't seen any problems at all that are caused by people trying to subclass classes that they shouldn't, so I'm wondering where this fear of bad subclass beh

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

To share some perspective, I come from working on 200k to 500k LOC systems, with the largest (aside linux kernel drivers) being ~2M loc/20,000 cpp files. I have done my share of objc coding, much of it for my own usage. My interest in swift has to do with finding a scalable solution for client s

Re: [swift-evolution] Change subscripts to use colons

> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution > wrote: > > Subscripts are a hybrid of properties and functions, since they have a > parameter list, as well as getters and setters, so use of either symbol will > be unusual in this case. > > However, I think a colon is more

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

Yes, app. Apps can be extended through plugins and you cannot write a plugin to an app without a library that exposes what you can do. That alone can expand my simple sample into a variety of examples: plugins. For the many types of folders I cannot enter details of my app now but check macOS'

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

You asked me to correct you and I shall: you're wrong. Although it seems like a filesystem representation here, this is not it and the subclassability of Entry and File is intended but Folder is a special type and I cannot allow more than the base type and a few controlled subclasses due 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 non-final

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 protocol conformance scenari

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

> Should I assume then you want so much this proposal to be dropped you didn't > even mind to look for the example so you wouldn't have to admit this proposal > is needed? Fine, here is the whole of that example. This list has thousands of messages, this topic alone is split into at least six t

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

> Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive > example to illustrate that this proposal could actually improve > something...even if there are cases which cannot be repelled with the simple > advice "just don't subclass", this would only be a basis to start talking

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy. I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many mod

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

Hey Swift Evolution! Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios: https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/-static-func-and-static-var-func-protocol-

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

Should I assume then you want so much this proposal to be dropped you didn't even mind to look for the example so you wouldn't have to admit this proposal is needed? Fine, here is the whole of that example. I'm currently working on an app which will have object representations of Files and Fold

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

Regards (From mobile) > On Jul 10, 2016, at 7:34 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz wrote: >> >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : >>> >>> >>> >>> Sent from my iPad >>> O

Re: [swift-evolution] Addition of a standardError OutputStream

What is the process for smaller issues like these? I’m guessing that this doesn’t need a proposal; where should it go? On bugs.swift.org ? > On Jul 8, 2016, at 16:33, Erica Sadun wrote: > > Right now it's more like "foo".write(to: &stream) but I agree that having to >

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I appreciate the desire for consistency but I really don't like this proposal. I agree with others who've said that it makes the code look heavy and that the extra parens only obscure the actual code, at least when the code is short. I don't think there is any way in which the parens make the code

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

> Am 10.07.2016 um 19:34 schrieb Matthew Johnson : > > > > Sent from my iPad > > On Jul 10, 2016, at 12:26 PM, Thorsten Seitz > wrote: > >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson >> >: >>> >>> >>> >>> Sent from my iPa

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

Sent from my iPad > On Jul 10, 2016, at 12:26 PM, Thorsten Seitz wrote: > > >> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : >> >> >> >> Sent from my iPad >> >>> On Jul 8, 2016, at 10:05 AM, Thorsten Seitz wrote: >>> >>> >>> Am 08.07.2016 um 15:59 schrieb Matthew Johnson : >>>

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

> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : > > > > Sent from my iPad > > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz > wrote: > >> >> >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson > >: >> >>> >>> >>> Sent from my iPa

Re: [swift-evolution] Swift-based Metal Shading Language

> > Using the same language/syntax would eliminate the taxing mental > > context-switch. > I don't understand. That's the point of C++ interop... You call the C++ APIs > from your Swift code. The topic of this discussion is not calling *existing* C++ APIs. It’s about the possibility of writing

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

Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to canc

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Just to be crystal clear, here is my vision. Currently Swift is heading in this direction: SomeType.staticMember == metatypeInstance.staticMember == SomeType.self.staticMember SomeType.init == metatypeInstance.init == SomeType.self.init SomeType.self -> SomeType.Type (metatype) SomeType -> Som

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Can you point me to some reading? I’m curious what exactly you’re talking about!? — I found a negative side effect of sealing T.Type. The problem appears lies in the dynamic is cast. Currently we could do something like this: func isInt(metatype: T.Type) -> Bool { return metatype is

Re: [swift-evolution] Swift-based Metal Shading Language

On Jul 10, 2016, at 01:17, Georgios Moschovitis wrote: >> I *think* it'd be better to add C++ interoperability to Swift. > > Wouldn’t it be better to have unified syntax across the board? e.g., > > int x; -vs- x: Int, etc? > > Using the same language/syntax would eliminate the taxing mental

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

It looks like this is touching on a small subset of the not-yet-designed reflection API (still tabled for 4.0?). I am interested to see what balance it strikes between declarations (eg. being able to reflect extensions declarations), types (eg reflecting type conformance), and operations (xxx.

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On Jul 4, 2016, at 5:32 PM, Andrew Trick via swift-evolution > wrote: > > >> On Jun 28, 2016, at 11:05 PM, Chris Lattner > > wrote: >> >> Hello Swift community, >> >> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through >> July 4, 2016. The

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

Hi Chris, Yes, I did read it again, subscribe to that strategy. I’ve perhaps over-emphasized the importance of the impact back-breaking changes .. Still.. The subject title was a bit overloaded too. I guess it’s between two extremes: that is, between (1) really freezing it and (2) using Swif

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Hello Chris, my main concern for this change is the lack of extensibility of metatypes. We can access the metatype through the .self postfix, which potentially will be removed in the future (only the postfix). Through an instance of such a metatype we can then access the static members and all

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

This has been a very interesting and educational thread. Thanks to everyone who kindly replied to me and explained things. Here is my 2¢… > * What is your evaluation of the proposal? +0 as it stands… +1 if there could be a reliable way for us to explicitly un-seal a sealed class for those time

Re: [swift-evolution] Swift-based Metal Shading Language

Regards (From mobile) > On Jul 10, 2016, at 11:25 AM, G B via swift-evolution > wrote: > > I feel like there are two totally different discussions happening here. One > is whether Swift needs better interoperability with C++, which it does. > Let’s just assume that that will happen. One

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

Regards (From mobile) On Jul 10, 2016, at 12:01 AM, Károly Lőrentey via swift-evolution wrote: >> On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: >> >> Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have >> the current setup by default? Why C++ x09/x11/x14 is also

Re: [swift-evolution] Swift-based Metal Shading Language

I feel like there are two totally different discussions happening here. One is whether Swift needs better interoperability with C++, which it does. Let’s just assume that that will happen. The other discussion, which I think was the intended topic of this thread, is whether the benefits of pa

  1   2   >