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

[Erica Sadun via swift-evolution]

> 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 experiments. Both of these scenarios add complexity for reasoning 
> (compare case B and case C in my example above).
> 
> Obviously, in code, whichever of statement A or B is first reached will 
> preclude execution of the other. But the whole point of control flow 
> statements is to provide an expressive way to branch when necessary. If we 
> agree that the complexity introduced by `continue` is worthwhile and useful, 
> then "if condition continue, else fallthrough" is just as legitimate a use 
> case as "if condition continue, else break."
> 
> As such, I'd conclude that I'm neutral on the proposal (I could do without 
> it, but it would be intriguing and Swifty to empower the switch statement 
> further). However, if adopted I'd strongly urge having all uses of continue 
> permitted. Including something like `continue case 0..<2 where y < z` if a 
> subsequent case is written as such, since after all cases are syntaxed like 
> labels.
> On Mon, Jul 11, 2016 at 00:44 Erica Sadun  > wrote:
> 
> > 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 & B because that 
> makes computing the possibilities unnecessarily complex and I cannot think of 
> a single real-world use-case where one would want to do both at the same time.
> 
> -- E
> 
> 

Can you give me an example where anyone would ever want to say:

case something: 
continue
fallthrough

-- E

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

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

[Xiaodi Wu via swift-evolution]

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
(compare case B and case C in my example above).

Obviously, in code, whichever of statement A or B is first reached will
preclude execution of the other. But the whole point of control flow
statements is to provide an expressive way to branch when necessary. If we
agree that the complexity introduced by `continue` is worthwhile and
useful, then "if condition continue, else fallthrough" is just as
legitimate a use case as "if condition continue, else break."

As such, I'd conclude that I'm neutral on the proposal (I could do without
it, but it would be intriguing and Swifty to empower the switch statement
further). However, if adopted I'd strongly urge having all uses of continue
permitted. Including something like `continue case 0..<2 where y < z` if a
subsequent case is written as such, since after all cases are syntaxed like
labels.
On Mon, Jul 11, 2016 at 00:44 Erica Sadun  wrote:

>
> > 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 & B because that
> makes computing the possibilities unnecessarily complex and I cannot think
> of a single real-world use-case where one would want to do both at the same
> time.
>
> -- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

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.

Literals enable you to write cross platform code with a minimum of 
redundant and platform-configured code.

In today's Swift, you can say:   let myColor = color literal and that code is 
cross-compatible for all Apple platforms, whether UIColor, NSColor, and SKColor.
If you write that same request as let myColor = UIColor(...), it will no longer 
compile on Cocoa.

I'm proposing to extend these existing behaviors to create common code 
inherently 
universal tasks with common structure: NSFont/UIFont, point2/CGPoint/NSPoint, 
etc

> To that end, I'd like to modestly suggest that #literal.foo (as already 
> written in the proposal) should be the canonical form of a literal in source 
> text, whereas #foo is the one you see used in the code editor.

I've already filed radars asking that the code editor let you see the raw 
unrendered literals
and heartily encourage duped radars to support that end.

> I'm not a fan of namespacing in #literal, because every literal should 
> obviously be a literal; I wouldn't ever recommend numerals fall under this 
> proposal as written, for instance.

The core team has suggested they'd like to use namespacing, especially with 
related
items that could otherwise spread and grow in an unmanaged way.

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

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

[Austin Zheng via swift-evolution]

> 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 week-long official review period.
> 
> Not all people "couldn’t be bothered” but had life events, such as moving 
> across states with four kids, that prevented them from being able to engage 
> during the official review period. 

I hope your move went smoothly. More generally, there will always be people 
with good reasons for not being able to participate in the review process, but 
the procedure is set: one week of formal discussion, followed by a decision by 
the core team. If a proposal should be re-reviewed or amended, someone should 
submit (or at least draft) a follow-up proposal; none of the other proposals 
that have been accepted have been taken up for re-review by the core team based 
merely on reviews that were submitted after the review period ended (and there 
have been at least a few whose acceptance was very controversial).

> 
> I’ve read through all of the posts that I see in my mailbox regarding this 
> topic and I’ve yet to see any real answer to the concerns of tooling, 
> typealias usage, closures, and code readability and maintainability concerns 
> under this new proposal. This is the closest I’ve seen (from Douglas Gregor a 
> few days ago):
> 
>> The core team’s intent is that one can add cosmetic labels to function 
>> types, but that those labels are not (cannot be) used at the call site, e.g.,
> 
> Do you have specific post in mind that addresses the these concerns? Maybe 
> I’m just missing them, but I really don’t see those addressed and they are 
> not mentioned in the proposal at all.
> 
> Let’s say I want to model a problem regarding some library functions that 
> work with resizing some image type. Today, if I did that, the tooling would 
> give me auto-completion for all of the parameter labels and the code is very 
> legible. 
> 
> Note that both `original` and `resized` get auto-completed for us here. This 
> provides great code clarity and insights. This is also self-documenting code.
> 
> However, under this proposal as accepted (as I understand it), we are left 
> with this:
> 
> func doResizeC(image: Image, completed: (Image, Image) -> Void) {
> let newData = image.data
> let newSize = image.size

You can still have labels in the type: `completed: (original: Image, resized: 
Image)`.

> 
> // do some work that's really slow...
> 
> completed(image, Image(data: newData, size: newSize))

This is definitely a problem. I am considering writing a follow-up proposal 
that would allow for compound naming of values of function type, which would 
alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was brought 
up a couple of times during the review thread. (This was going to be part of 
the original proposal, but was removed for various reasons.)

> }
> 
> -David

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

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

[Erica Sadun via swift-evolution]

> 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 & B because that makes 
computing the possibilities unnecessarily complex and I cannot think of a 
single real-world use-case where one would want to do both at the same time.

-- E


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

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

[Tino Heth via swift-evolution]

> 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 that exists at all:
There are no other parties that ship frameworks that way, and I don't think 
this should change.

So the benefits of this proposal would exist for Apple alone, and I can 
understand why sealed is convenient for an UIKit-engineer.
It is tempting to aim for the easiest solution, but it is smarter to take the 
route that's better for the customer (and we happen to be the customers).
And, as others pointed out before, Cupertino is free to diverge from the 
defaults in either direction, so it is only a little effort to have "sealed by 
default" without the bad side effects.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

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 proposal) should be the canonical form of a literal in
source text, whereas #foo is the one you see used in the code editor.
I'm not a fan of namespacing in #literal, because every literal should
obviously be a literal; I wouldn't ever recommend numerals fall under
this proposal as written, for instance.
 
Sincerely,
  Zachary Waldowski
  z...@waldowski.me
 
 
On Sun, Jul 10, 2016, at 08:48 PM, Erica Sadun via swift-evolution wrote:
> 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[1]
>  * Status: TBD
>  * Review manager: TBD
> Introduction
> This proposal expands Swift's language literals to include common cross-
> platform concepts that need not require.
> Motivation
> A Swift literal represents a fixed value in source code. A literal can
> be a string, a number (for example an integer), a compound value (such
> as an array), or one of several predefined "playground" literals
> including colors, resource file paths, and resource images.
> Swift literals do not have types. They are universal representations
> that are evaluated and their types inferred from the context in which
> they are used. Because their nature is typeless, the same color
> literal can initialize UIColor, NSColor, and SKColor instances. The
> type cannot be inferred from the source without the context of its
> destination.


> let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615,
> blue: 0.4035313427, alpha: 1)
>
> Detailed Design


> *Namespace redesign*** Kind Literal Parameters Color
> `#literal.color(red:, green:, blue:, alpha:)` floating point values
> Image `#literal.image(resourceName:)` String with resource name File
> `#literal.file(resourceName:)` String with resource name *General***
> Kind Literal Parameters Sound `#literal.audio(resourceName:)` String
> with resource name URL `#literal.url(string:)`,
> `#literal.url(filePath:)` String with resource location Font
> `#literal.font(face:, size:)` string, floating point Date
> `#literal.date(timeInterval:)` floating point offset from Unix epoch
> Unicode `#literal.unicode(name:)` Official unicode name, e.g.
> `#literal.unicode(name:"DOG FACE")` *Geometry*** Kind Literal
> Parameters Point `#literal.point(x:, y:)`, `#literal.point(x:, y:,
> z:)`, `#literal.point(x:, y:, z:, w:)` floating point values Vector
> `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,
> `#literal.vector(dx:, dy:, dz:, dw:)` floating point Size
> `#literal.size(width:, height:)`, `#literal.size(width:, height:,
> depth:)` floating point Rect `#literal.rect(x:, y:, width:, height:)`
> floating point Affine Transform
> `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,
> `#literal.affineTransform(translateX:, translateY:)`,
> `#literal.affineTransform(scaleY:, scaleY:)`,
> `#literal.affineTransform(rotation:)`, floating point Bezier Path
> `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 
> 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-
> 2.08 4z")` String with SVG path notation
> Not included:
> Attributed Strings: I would like to see a way to define attributed
> strings (using some system like CSS/HTML) but could not think up a
> simple representation similar to the others mentioned in the
> preceding table.
> JSON Literals: Again, probably too complex and possibly not worth
> their weight. If they could exist, they'd have to be imported via a
> resource or URL and transformed to a local type.
> Impact on Existing Code
> This proposal is purely additive.
> Alternatives Considered
> Using distinct literal names without subsuming them into a namespaced
> umbrella.
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 

Links:

  1. http://github.com/erica
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 { … }
> }
> 
> Sorry if that wasn't clear.
> 
> This would be to better reflect the property-like nature of access.

It all depends on whether a subscript is more function-y or property-y, and 
don't forget subscripts can take parameters and labels.

let y = myArrayOfStrings[safeIndex: 2, fallback: "foo"]

-- E

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

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

[Erica Sadun via swift-evolution]

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 
> 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, 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 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? How many of these reach the default case? What happens if 
>>> I append `fallthrough` at the end of case D? What happens if I move case B 
>>> after case D? (Yes, I know it is possible to figure it out [my 
>>> understanding of the answer to the first question is appended below], but I 
>>> hope you'll agree with me that this is much more difficult to decipher than 
>>> any switch statement that's currently possible.)
>>> 
>>> ```
>>> switch x /* or y, or z */ {
>>> case A:
>>>   // ...
>>>   continue
>>> case B:
>>>   // ...
>>>   if C ~= x /* or y, or z, whichever is switched over */ {
>>> continue
>>>   }
>>>   fallthrough
>> 
>> I'd say it would be fair to disallow continue and fallthrough to occur in 
>> the same clause
>> 
>> Why should `fallthrough` be prohibited but implicit `break` become mandatory 
>> in such a clause? If `continue` were to be implemented in this context, I'd 
>> want the full power of the keyword, including being allowed to `continue` 
>> conditionally, `continue` with different labels, and round out the case if 
>> no conditions are satisfied with either `fallthrough` or `break` (or, for 
>> that matter, `return`, etc.).
> 
> I do not understand. `break` is already implicit unless no other code is 
> used. 
> 
> case something:
>if condition { continue }
>// ends here. the compiler knows not to go forward and it's not an empty 
> clause
> case somethingElse:
> 
> `fallthrough` means "ignore the next case statement and execute its clause".
> 
> -- E

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

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

[Saagar Jha via swift-evolution]

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 is an extreme 
example. 

Sent from my Apple Watch

On Jul 10, 2016, at 20:48, Erica Sadun via swift-evolution 
 wrote:

> 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
> Introduction
> 
> This proposal expands Swift's language literals to include common 
> cross-platform concepts that need not require.
> 
> Motivation
> 
> A Swift literal represents a fixed value in source code. A literal can be a 
> string, a number (for example an integer), a compound value (such as an 
> array), or one of several predefined "playground" literals including colors, 
> resource file paths, and resource images.
> 
> Swift literals do not have types. They are universal representations that are 
> evaluated and their types inferred from the context in which they are used. 
> Because their nature is typeless, the same color literal can initialize 
> UIColor, NSColor, and SKColor instances. The type cannot be inferred from the 
> source without the context of its destination.
> 
> let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 
> 0.4035313427, alpha: 1)
> Detailed Design
> 
> Namespace redesign
> Kind  Literal Parameters
> Color `#literal.color(red:, green:, blue:, alpha:)`   floating point values
> Image `#literal.image(resourceName:)` String with resource name
> File  `#literal.file(resourceName:)`  String with resource name
> General
> Kind  Literal Parameters
> Sound `#literal.audio(resourceName:)` String with resource name
> URL   `#literal.url(string:)`, `#literal.url(filePath:)`  String with 
> resource location
> Font  `#literal.font(face:, size:)`   string, floating point
> Date  `#literal.date(timeInterval:)`  floating point offset from Unix epoch
> Unicode   `#literal.unicode(name:)`   Official unicode name, e.g. 
> `#literal.unicode(name:"DOG FACE")`
> Geometry
> Kind  Literal Parameters
> Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, 
> `#literal.point(x:, y:, z:, w:)`floating point values
> Vector`#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, 
> `#literal.vector(dx:, dy:, dz:, dw:)`floating point
> Size  `#literal.size(width:, height:)`, `#literal.size(width:, height:, 
> depth:)`  floating point
> Rect  `#literal.rect(x:, y:, width:, height:)`floating point
> Affine Transform  `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, 
> `#literal.affineTransform(translateX:, translateY:)`, 
> `#literal.affineTransform(scaleY:, scaleY:)`, 
> `#literal.affineTransform(rotation:)`, floating point
> Bezier Path   `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 
> 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")`String with SVG 
> path notation
> Not included:
> 
> Attributed Strings: I would like to see a way to define attributed strings 
> (using some system like CSS/HTML) but could not think up a simple 
> representation similar to the others mentioned in the preceding table.
> 
> JSON Literals: Again, probably too complex and possibly not worth their 
> weight. If they could exist, they'd have to be imported via a resource or URL 
> and transformed to a local type.
> 
> Impact on Existing Code
> 
> This proposal is purely additive.
> 
> Alternatives Considered
> 
> Using distinct literal names without subsuming them into a namespaced 
> umbrella.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Owens II via swift-evolution]

> 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 would be 
>>> actively prohibited. That’s useful information for the developer to have, 
>>> and if the compiler doesn’t know them in some way, you can be assured 
>>> Xcode’s autocomplete won’t see them. 
>> 
>> 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 week-long official review period.

Not all people "couldn’t be bothered” but had life events, such as moving 
across states with four kids, that prevented them from being able to engage 
during the official review period. 

I’ve read through all of the posts that I see in my mailbox regarding this 
topic and I’ve yet to see any real answer to the concerns of tooling, typealias 
usage, closures, and code readability and maintainability concerns under this 
new proposal. This is the closest I’ve seen (from Douglas Gregor a few days 
ago):

> The core team’s intent is that one can add cosmetic labels to function types, 
> but that those labels are not (cannot be) used at the call site, e.g.,

Do you have specific post in mind that addresses the these concerns? Maybe I’m 
just missing them, but I really don’t see those addressed and they are not 
mentioned in the proposal at all.

Let’s say I want to model a problem regarding some library functions that work 
with resizing some image type. Today, if I did that, the tooling would give me 
auto-completion for all of the parameter labels and the code is very legible. 

struct Size {
var x: Int
var y: Int
}

struct Image {
var data: Data
var size: Size
// lots more properties...
}

typealias ImageResizedCallback = (original: Image, resized: Image) -> Void

func doResizeA(image: Image, completed: ImageResizedCallback) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(original: image, resized: Image(data: newData, size: newSize))
}

func doResizeB(image: Image, completed: (original: Image, resized: Image) -> 
Void) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(original: image, resized: Image(data: newData, size: newSize))
}

In either approach, `doResizeA` with a named callback or `doResizeB` with an 
explicit parameter type offer benefits that are lost under this proposal.

let someAsset = Image(data: Data(), size: Size(x: 100, y: 100))

doResizeA(image: someAsset, completed: { (original, resized) in
print("doResizeA - original: \(original), resized: \(resized)")
})

doResizeB(image: someAsset, completed: { (original, resized) in
print("doResizeB - original: \(original), resized: \(resized)")
})

Note that both `original` and `resized` get auto-completed for us here. This 
provides great code clarity and insights. This is also self-documenting code.

However, under this proposal as accepted (as I understand it), we are left with 
this:

func doResizeC(image: Image, completed: (Image, Image) -> Void) {
let newData = image.data
let newSize = image.size

// do some work that's really slow...

completed(image, Image(data: newData, size: newSize))
}

This code is no longer self-documenting. I have no idea at looking at the call 
signature which order the images to `completed` should be.

Further, I get no help here when trying to use it:

doResizeC(image: someAsset) { (<#Image#>, <#Image#>) in
<#code#>
}

What do I label for the two images? This is a workflow regression. Yes, maybe 
the underlying model is more correct. However, this comes at a burden to 
actually authoring and maintaining the code. To me, that’s a truly unfortunate 
cost.

So now I probably write this:

doResizeC(image: someAsset) {
print("doResizeC1 - original: \($0), resized: \($1)")
}

Or, if I happen to know or look-up the order, I can fill in the labels myself:

doResizeC(image: someAsset, completed: { (original, resized) in
print("doResizeC2 - original: \(original), resized: \(resized)")
})

Further, we are able to turn runtime errors into compile-time checks when 
refactoring the signatures in the `doResizeA` and `doResizeB` functions - e.g. 
change the order of `original` and `resized` and you’ll get the compiler 
errors. This no longer happens under this proposal because the labels are 
erased. One way around that is to use types to solve this problem, but Swift 
provides no convenient way to have two `Image` types that share the same 
implementation but are considered as different types (sure, I could box 

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

[Jacob Bandes-Storch via swift-evolution]

+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
function bodies.

...and now that I'm thinking about it, I'm almost tempted to recommend
"subscript[_ example: Int]: Element". Is that too crazy?

Jacob

On Sun, Jul 10, 2016 at 4:18 PM, James Froggatt via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 access.
>
> From James F
>
> On 10 Jul 2016, at 23:57, Brent Royal-Gordon 
> wrote:
>
> >> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution <
> swift-evolution@swift.org> 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 suitable, since it implies the
> possibility to set the value.
> >
> > Can you show us an example of the current syntax and your proposed
> replacement? I'm not sure what you actually mean by "use colons".
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

+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, 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 { … }
>> }
>>
>> 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 access.
>>
>> From James F
>>
>> On 10 Jul 2016, at 23:57, Brent Royal-Gordon 
>> wrote:
>>
>> >> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution <
>> swift-evolution@swift.org> 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 suitable, since it implies the
>> possibility to set the value.
>> >
>> > Can you show us an example of the current syntax and your proposed
>> replacement? I'm not sure what you actually mean by "use colons".
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Patrick Pijnappel via swift-evolution]

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 { … }
> }
>
> 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 access.
>
> From James F
>
> On 10 Jul 2016, at 23:57, Brent Royal-Gordon 
> wrote:
>
> >> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution <
> swift-evolution@swift.org> 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 suitable, since it implies the
> possibility to set the value.
> >
> > Can you show us an example of the current syntax and your proposed
> replacement? I'm not sure what you actually mean by "use colons".
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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, 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 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? How many of these reach the default case? What
>> happens if I append `fallthrough` at the end of case D? What happens if I
>> move case B after case D? (Yes, I know it is possible to figure it out [my
>> understanding of the answer to the first question is appended below], but I
>> hope you'll agree with me that this is much more difficult to decipher than
>> any switch statement that's currently possible.)
>>
>> ```
>> switch x /* or y, or z */ {
>> case A:
>>   // ...
>>   continue
>> case B:
>>   // ...
>>   if C ~= x /* or y, or z, whichever is switched over */ {
>> continue
>>   }
>>   fallthrough
>>
>>
>> I'd say it would be fair to disallow continue and fallthrough to occur in
>> the same clause
>>
>
> Why should `fallthrough` be prohibited but implicit `break` become
> mandatory in such a clause? If `continue` were to be implemented in this
> context, I'd want the full power of the keyword, including being allowed to
> `continue` conditionally, `continue` with different labels, and round out
> the case if no conditions are satisfied with either `fallthrough` or
> `break` (or, for that matter, `return`, etc.).
>
>
> I do not understand. `break` is already implicit unless no other code is
> used.
>
> case something:
>if condition { continue }
>// ends here. the compiler knows not to go forward and it's not an
> empty clause
> case somethingElse:
>
> `fallthrough` means "ignore the next case statement and execute its
> clause".
>
> -- E
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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?
> >
> > 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 `size` seems ill-suited for literal representation, as
> opposed to a shape (e.g. rectangle). Why is it a two-dimensional size
> anyway? Also, since literals have no type, is there any scenario in which a
> `size` literal of a certain width and height and a `point` literal with a
> certain x and y coordinate are meaningfully different?
> >
> > Finally, several of these look like string literals with types. For
> instance, `unicode` seems to reflect a desire to refer to characters by
> their official names. Perhaps that could be proposed instead as a new
> escaping syntax for strings? Something like `let string = "\u{{DOG FACE}}"`
> might be pretty handy.
>
> It doesn't have to be "represented". It can be used as `#literal.point(x:
> 3.5, y: 2.0)` without any "pretty" picture.
>
> A literal offers a typeless universal value that can be interpreted by a
> conforming type as a representation of itself, so you can have:
>
> let x: CGPoint = #literal.point(x: 3.5, y: 2.0)
> let x: NSPoint = #literal.point(x: 3.5, y: 2.0)
> let x: float2 = #literal.point(x: 3.5, y: 2.0)
>
> -- E
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 coordinate, would we just see a point floating on the screen?
> 
> Something like `size` seems ill-suited for literal representation, as opposed 
> to a shape (e.g. rectangle). Why is it a two-dimensional size anyway? Also, 
> since literals have no type, is there any scenario in which a `size` literal 
> of a certain width and height and a `point` literal with a certain x and y 
> coordinate are meaningfully different?
> 
> Finally, several of these look like string literals with types. For instance, 
> `unicode` seems to reflect a desire to refer to characters by their official 
> names. Perhaps that could be proposed instead as a new escaping syntax for 
> strings? Something like `let string = "\u{{DOG FACE}}"` might be pretty handy.

It doesn't have to be "represented". It can be used as `#literal.point(x: 3.5, 
y: 2.0)` without any "pretty" picture.

A literal offers a typeless universal value that can be interpreted by a 
conforming type as a representation of itself, so you can have:

let x: CGPoint = #literal.point(x: 3.5, y: 2.0)
let x: NSPoint = #literal.point(x: 3.5, y: 2.0)
let x: float2 = #literal.point(x: 3.5, y: 2.0)

-- E


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

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

[Erica Sadun via swift-evolution]

> 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 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? How many of these reach the default case? What happens if 
>> I append `fallthrough` at the end of case D? What happens if I move case B 
>> after case D? (Yes, I know it is possible to figure it out [my understanding 
>> of the answer to the first question is appended below], but I hope you'll 
>> agree with me that this is much more difficult to decipher than any switch 
>> statement that's currently possible.)
>> 
>> ```
>> switch x /* or y, or z */ {
>> case A:
>>   // ...
>>   continue
>> case B:
>>   // ...
>>   if C ~= x /* or y, or z, whichever is switched over */ {
>> continue
>>   }
>>   fallthrough
> 
> I'd say it would be fair to disallow continue and fallthrough to occur in the 
> same clause
> 
> Why should `fallthrough` be prohibited but implicit `break` become mandatory 
> in such a clause? If `continue` were to be implemented in this context, I'd 
> want the full power of the keyword, including being allowed to `continue` 
> conditionally, `continue` with different labels, and round out the case if no 
> conditions are satisfied with either `fallthrough` or `break` (or, for that 
> matter, `return`, etc.).

I do not understand. `break` is already implicit unless no other code is used. 

case something:
   if condition { continue }
   // ends here. the compiler knows not to go forward and it's not an empty 
clause
case somethingElse:

`fallthrough` means "ignore the next case statement and execute its clause".

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 shared
> a use case where public-but-non-subclassable made things work out much
> better with required initializers. This one has a bit more ideology in it.)
>
> As many people have said already, this proposal is quite beneficial to
> library designers attempting to reason about their code, not just now but
> in the future as well. The model laid out in the Library Evolution
> document  (often
> referred to as “resilience”) supports Swift libraries that want to preserve
> a stable binary and source interface.
>
> In the Swift 2 model (and what’s currently described in that document), a
> public class must be final or non-final at the time it is published. It’s
> clearly not safe to *add* ‘final' in a later version of the library,
> because a client might already have a subclass; it’s also not safe to
> *remove* ‘final’ because existing clients may have been compiled assuming
> there are no subclasses.
>
> (Of course, we can remove this optimization, and make ‘final’ a semantic
> contract only. I’m deliberately avoiding most discussion of performance,
> but in this parenthetical I’ll note that Swift makes it possible to write
> code that is *slower* than Objective-C. This is considered acceptable
> because the compiler can often optimize it for a particular call site. For
> those who want more information about the current implementation of some of
> Swift’s features, I suggest watching the “Understanding Swift Performance
> ” talk from this
> year’s WWDC.)
>
> With this proposal, a public class can be non-publicly-subclassable or
> publicly-subclassable. Once a class is publicly-subclassable (“open”), you
> can’t go back, of course. But a class that’s not initially open could
> *become* open in a future release of the library. All existing clients
> would already be equipped to deal with this, because there might be
> subclasses *inside* the library. On the other hand, the class can *also* be
> marked ‘final’, if the library author later realizes there will never be
> any subclasses and that both client authors and the compiler should know
> this.
>
> One point that’s not covered in this proposal is whether making a class
> ‘open’ applies retroactively, i.e. if MagicLib 1.2 is the first version
> that makes the Magician class ‘open’, can clients deploy back to MagicLib
> 1.0 and expect their subclasses to work? My inclination is to say no; if
> it’s possible for a non-open method to be overridden in the future, a
> library author has to write their library as if it will be overridden now,
> and there’s no point in making it non-open in the first place. That would
> make ‘open’ a “versioned attribute
> ”
> in the terminology of Library Evolution, whatever the syntax ends up being.
>
> ---
>
> Okay, so why is this important?
>
> It all comes down to reasoning about your program’s behavior. When you use
> a class, you’re relying on the documented behavior of that class. More
> concretely, the methods on the class have preconditions
> (“performSegue(withIdentifier:sender:) should not be called on a view
> controller that didn’t come from a storyboard”) and postconditions (“after
> calling loadViewIfNeeded(), the view controller’s view will be loaded”).
> When you call a method, you’re responsible for satisfying its preconditions
> so it can deliver on the postconditions.
>
> I used UIViewController as an example, but it applies just as much to your
> own methods. When you call a method in your own module—maybe written by
> you, maybe by a coworker, maybe by an open source contributor—you’re
> expecting some particular behavior and output given the inputs and the
> current state of the program. That is, you just need to satisfy its
> preconditions so it can deliver on the postconditions. If it’s a method in
> your module, though, you might not have taken the trouble to formalize the
> preconditions and postconditions, since you can just go look at the
> implementation. Even if your expectations are violated, you’ll probably
> notice, because the conflict of understanding is within your own module.
>
> Public overriding changes all this. While an overridable method may have
> particular preconditions and postconditions, it’s possible that the
> overrider will get that wrong, which means the library author can no longer
> reason about the behavior of their program. If they do a poor job
> documenting the preconditions and postconditions, the client and the
> library will almost certainly disagree about the expected behavior of a
> 

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

[Xiaodi Wu via swift-evolution]

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 statements are executed in the
> following switch statement? How many of these reach the default case? What
> happens if I append `fallthrough` at the end of case D? What happens if I
> move case B after case D? (Yes, I know it is possible to figure it out [my
> understanding of the answer to the first question is appended below], but I
> hope you'll agree with me that this is much more difficult to decipher than
> any switch statement that's currently possible.)
>
> ```
> switch x /* or y, or z */ {
> case A:
>   // ...
>   continue
> case B:
>   // ...
>   if C ~= x /* or y, or z, whichever is switched over */ {
> continue
>   }
>   fallthrough
>
>
> I'd say it would be fair to disallow continue and fallthrough to occur in
> the same clause
>

Why should `fallthrough` be prohibited but implicit `break` become
mandatory in such a clause? If `continue` were to be implemented in this
context, I'd want the full power of the keyword, including being allowed to
`continue` conditionally, `continue` with different labels, and round out
the case if no conditions are satisfied with either `fallthrough` or
`break` (or, for that matter, `return`, etc.).


>
> case C:
>   // ...
>   if B ~= x /* or y, or z, whichever is switched over */ {
> continue
>   }
> case D:
>   // ...
> default:
>   // ...
> }
> ```
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 `size` seems ill-suited for literal representation, as
opposed to a shape (e.g. rectangle). Why is it a two-dimensional size
anyway? Also, since literals have no type, is there any scenario in which a
`size` literal of a certain width and height and a `point` literal with a
certain x and y coordinate are meaningfully different?

Finally, several of these look like string literals with types. For
instance, `unicode` seems to reflect a desire to refer to characters by
their official names. Perhaps that could be proposed instead as a new
escaping syntax for strings? Something like `let string = "\u{{DOG FACE}}"`
might be pretty handy.


On Sun, Jul 10, 2016 at 10:48 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> 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
>
>
> 
> Introduction
>
> This proposal expands Swift's language literals to include common
> cross-platform concepts that need not require.
> 
> Motivation
>
> A Swift literal represents a fixed value in source code. A literal can be
> a string, a number (for example an integer), a compound value (such as an
> array), or one of several predefined "playground" literals including
> colors, resource file paths, and resource images.
>
> Swift literals do not have types. They are universal representations that
> are evaluated and their types inferred from the context in which they are
> used. Because their nature is typeless, the same color literal can
> initialize UIColor, NSColor, and SKColor instances. The type cannot be
> inferred from the source without the context of its destination.
>
> let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 
> 0.4035313427, alpha: 1)
>
>
> Detailed
> Design
> *Namespace redesign*
> KindLiteralParameters
> Color `#literal.color(red:, green:, blue:, alpha:)` floating point values
> Image `#literal.image(resourceName:)` String with resource name
> File `#literal.file(resourceName:)` String with resource name
> *General*
> KindLiteralParameters
> Sound `#literal.audio(resourceName:)` String with resource name
> URL `#literal.url(string:)`, `#literal.url(filePath:)` String with
> resource location
> Font `#literal.font(face:, size:)` string, floating point
> Date `#literal.date(timeInterval:)` floating point offset from Unix epoch
> Unicode `#literal.unicode(name:)` Official unicode name, e.g.
> `#literal.unicode(name:"DOG FACE")`
> *Geometry*
> KindLiteralParameters
> Point `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`,
> `#literal.point(x:, y:, z:, w:)` floating point values
> Vector `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`,
> `#literal.vector(dx:, dy:, dz:, dw:)` floating point
> Size `#literal.size(width:, height:)`, `#literal.size(width:, height:,
> depth:)`  floating point
> Rect `#literal.rect(x:, y:, width:, height:)` floating point
> Affine Transform `#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`,
> `#literal.affineTransform(translateX:, translateY:)`,
> `#literal.affineTransform(scaleY:, scaleY:)`,
> `#literal.affineTransform(rotation:)`,  floating point
> Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32,
> 0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")` String with SVG
> path notation
> Not
> included:
>
> Attributed Strings: I would like to see a way to define attributed
> strings (using some system like CSS/HTML) but could not think up a simple
> representation similar to the others mentioned in the preceding table.
>
> JSON Literals: Again, probably too complex and possibly not worth their
> weight. If they could exist, they'd have to be imported via a resource or
> URL and transformed to a local type.
>
> Impact
> on Existing Code
>
> This proposal is purely additive.
>
> Alternatives
> Considered
> Using distinct literal names without subsuming them into a namespaced
> umbrella.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

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

[Xiaodi Wu via swift-evolution]

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 `fallthrough`, a
> condition implicitly excludes all previous conditions. That is, if I write
> `switch .. { case a: ...; case b: ...; case c: ... }`, my condition `c` is
> really `!a && !b && c`. With more flexible control flow within a switch
> statement, reasoning about what cases are matched by any particular
> condition after the first becomes increasingly difficult.
>
> In the current Swift, absent `fallthrough`, the statement execution ends
> and no other statements are evaluated after the first match.
>
> With `fallthrough` the current clause executes and the next clause
> executes, and then the statement execution ends.
>
> With `continue`, the current clause executes and the switch continues
> searching for a matching pattern as if a pattern has not yet been matched.
>

I understand. What I'm saying is that control flow becomes more difficult
to reason through in a scenario as follows, which is not possible currently:

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? How many of these reach the default case? What
happens if I append `fallthrough` at the end of case D? What happens if I
move case B after case D? (Yes, I know it is possible to figure it out [my
understanding of the answer to the first question is appended below], but I
hope you'll agree with me that this is much more difficult to decipher than
any switch statement that's currently possible.)

```
switch x /* or y, or z */ {
case A:
  // ...
  continue
case B:
  // ...
  if C ~= x /* or y, or z, whichever is switched over */ {
continue
  }
  fallthrough
case C:
  // ...
  if B ~= x /* or y, or z, whichever is switched over */ {
continue
  }
case D:
  // ...
default:
  // ...
}
```

[For switch x: statements in cases A and C only, not the default; for
switch y: statements in case B, C and D, not the default; for switch z:
statements in cases B and C, and in the default]

Finally, a really neat thing about `continue` in Swift is the ability to
use labels; would you propose allowing that here? If so, could I label
individual cases and have pattern matching resume at that case? How about
resuming at a previous case? It'd be neat. It'd also make it possible to
make an infinite loop out of a switch statement...


-- E
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Extending Swift Literals

[Erica Sadun via swift-evolution]

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
 
Introduction

This proposal expands Swift's language literals to include common 
cross-platform concepts that need not require.

 
Motivation

A Swift literal represents a fixed value in source code. A literal can be a 
string, a number (for example an integer), a compound value (such as an array), 
or one of several predefined "playground" literals including colors, resource 
file paths, and resource images.

Swift literals do not have types. They are universal representations that are 
evaluated and their types inferred from the context in which they are used. 
Because their nature is typeless, the same color literal can initialize 
UIColor, NSColor, and SKColor instances. The type cannot be inferred from the 
source without the context of its destination.

let color = #colorLiteral(red: 0.8100712299, green: 0.1511939615, blue: 
0.4035313427, alpha: 1)
 
Detailed
 Design

Namespace redesign
KindLiteral Parameters
Color   `#literal.color(red:, green:, blue:, alpha:)`   floating point values
Image   `#literal.image(resourceName:)` String with resource name
File`#literal.file(resourceName:)`  String with resource name
General
KindLiteral Parameters
Sound   `#literal.audio(resourceName:)` String with resource name
URL `#literal.url(string:)`, `#literal.url(filePath:)`  String with 
resource location
Font`#literal.font(face:, size:)`   string, floating point
Date`#literal.date(timeInterval:)`  floating point offset from Unix epoch
Unicode `#literal.unicode(name:)`   Official unicode name, e.g. 
`#literal.unicode(name:"DOG FACE")`
Geometry
KindLiteral Parameters
Point   `#literal.point(x:, y:)`, `#literal.point(x:, y:, z:)`, 
`#literal.point(x:, y:, z:, w:)`floating point values
Vector  `#literal.vector(dx:, dy:)`, `#literal.vector(dx:, dy:, dz:)`, 
`#literal.vector(dx:, dy:, dz:, dw:)`floating point
Size`#literal.size(width:, height:)`, `#literal.size(width:, height:, 
depth:)`  floating point
Rect`#literal.rect(x:, y:, width:, height:)`floating point
Affine Transform`#literal.affineTransform(a:,b:,c:,d:,tx:,ty:)`, 
`#literal.affineTransform(translateX:, translateY:)`, 
`#literal.affineTransform(scaleY:, scaleY:)`, 
`#literal.affineTransform(rotation:)`, floating point
Bezier Path `#literal.bezier("M92.21,24.29H75L73,17a8.32,8.32, 
0,0,0-8.27-6.74H34.55A7.69,7.69,0,0,0,27,16.6l-2.08 4z")`String with SVG 
path notation
 
Not
 included:

Attributed Strings: I would like to see a way to define attributed strings 
(using some system like CSS/HTML) but could not think up a simple 
representation similar to the others mentioned in the preceding table.

JSON Literals: Again, probably too complex and possibly not worth their weight. 
If they could exist, they'd have to be imported via a resource or URL and 
transformed to a local type.

 
Impact
 on Existing Code

This proposal is purely additive.

 
Alternatives
 Considered

Using distinct literal names without subsuming them into a namespaced umbrella.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Erica Sadun via swift-evolution]

> 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 conditions. That is, if I write 
> `switch .. { case a: ...; case b: ...; case c: ... }`, my condition `c` is 
> really `!a && !b && c`. With more flexible control flow within a switch 
> statement, reasoning about what cases are matched by any particular condition 
> after the first becomes increasingly difficult.

In the current Swift, absent `fallthrough`, the statement execution ends and no 
other statements are evaluated after the first match.

With `fallthrough` the current clause executes and the next clause executes, 
and then the statement execution ends.

With `continue`, the current clause executes and the switch continues searching 
for a matching pattern as if a pattern has not yet been matched.

-- E

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

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

[Erica Sadun via swift-evolution]

> 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 labeled and the `continue` must 
use that label to differentiate between switch continuation and loop 
continuation.

Updated gist: https://gist.github.com/erica/04835de3d3d9121ef7308dd9b093158a

-- E

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

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

[Jordan Rose via swift-evolution]

[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 initializers. This one has a bit more ideology in it.)

As many people have said already, this proposal is quite beneficial to library 
designers attempting to reason about their code, not just now but in the future 
as well. The model laid out in the Library Evolution document 
 (often referred to as 
“resilience”) supports Swift libraries that want to preserve a stable binary 
and source interface.

In the Swift 2 model (and what’s currently described in that document), a 
public class must be final or non-final at the time it is published. It’s 
clearly not safe to add ‘final' in a later version of the library, because a 
client might already have a subclass; it’s also not safe to remove ‘final’ 
because existing clients may have been compiled assuming there are no 
subclasses.

(Of course, we can remove this optimization, and make ‘final’ a semantic 
contract only. I’m deliberately avoiding most discussion of performance, but in 
this parenthetical I’ll note that Swift makes it possible to write code that is 
slower than Objective-C. This is considered acceptable because the compiler can 
often optimize it for a particular call site. For those who want more 
information about the current implementation of some of Swift’s features, I 
suggest watching the “Understanding Swift Performance 
” talk from this year’s 
WWDC.)

With this proposal, a public class can be non-publicly-subclassable or 
publicly-subclassable. Once a class is publicly-subclassable (“open”), you 
can’t go back, of course. But a class that’s not initially open could become 
open in a future release of the library. All existing clients would already be 
equipped to deal with this, because there might be subclasses inside the 
library. On the other hand, the class can also be marked ‘final’, if the 
library author later realizes there will never be any subclasses and that both 
client authors and the compiler should know this.

One point that’s not covered in this proposal is whether making a class ‘open’ 
applies retroactively, i.e. if MagicLib 1.2 is the first version that makes the 
Magician class ‘open’, can clients deploy back to MagicLib 1.0 and expect their 
subclasses to work? My inclination is to say no; if it’s possible for a 
non-open method to be overridden in the future, a library author has to write 
their library as if it will be overridden now, and there’s no point in making 
it non-open in the first place. That would make ‘open’ a “versioned attribute 
”
 in the terminology of Library Evolution, whatever the syntax ends up being.

---

Okay, so why is this important?

It all comes down to reasoning about your program’s behavior. When you use a 
class, you’re relying on the documented behavior of that class. More 
concretely, the methods on the class have preconditions 
(“performSegue(withIdentifier:sender:) should not be called on a view 
controller that didn’t come from a storyboard”) and postconditions (“after 
calling loadViewIfNeeded(), the view controller’s view will be loaded”). When 
you call a method, you’re responsible for satisfying its preconditions so it 
can deliver on the postconditions.

I used UIViewController as an example, but it applies just as much to your own 
methods. When you call a method in your own module—maybe written by you, maybe 
by a coworker, maybe by an open source contributor—you’re expecting some 
particular behavior and output given the inputs and the current state of the 
program. That is, you just need to satisfy its preconditions so it can deliver 
on the postconditions. If it’s a method in your module, though, you might not 
have taken the trouble to formalize the preconditions and postconditions, since 
you can just go look at the implementation. Even if your expectations are 
violated, you’ll probably notice, because the conflict of understanding is 
within your own module.

Public overriding changes all this. While an overridable method may have 
particular preconditions and postconditions, it’s possible that the overrider 
will get that wrong, which means the library author can no longer reason about 
the behavior of their program. If they do a poor job documenting the 
preconditions and postconditions, the client and the library will almost 
certainly disagree about the expected behavior of a particular method, and the 
program won’t work correctly.

"Doesn’t a library author have to figure out the preconditions and 
postconditions for a method anyway when making it public?" Well, not to the 
same 

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

[Shawn Erickson via swift-evolution]

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 external surface and contract...which
if leveraged well will help with robustness, testability, and flexibility
in future revisions.

-Shawn

On Sun, Jul 10, 2016 at 10:53 PM Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution <
> swift-evolution@swift.org> 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 proposal won’t turn bad API designers into good ones.
> Crappy APIs are still going to be crappy with or without this. In the
> immortal quote apparently due to Lawrence Flon: “There is not now, nor has
> there ever been, nor will there ever be, any programming language in which
> it is the least bit difficult to write bad code.”
>
> The justification for this proposal is all about supporting the people who
> are working to design library APIs right, and about maintaining consistency
> with the design philosophy of Swift. To wit: in Swift, where there’s a
> default choice, it’s the safe one; where there’s a consequential design
> decision, it’s explicit.
>
> Rod Brown hit the crux of it: sealed → open is safe for existing API
> clients, but open → sealed is a breaking change. “Sealed” is thus the safer
> choice, and “open” is a consequential design decision. Given the general
> precedent and philosophy of Swift, competent API designers might reasonably
> be taken aback that open is the default. In fact, given the habit Swift
> encourages of leaning on compiler verification, this is a potential source
> of designer error.
>
> • • •
>
> For those who think that discouraging inheritance by default is something
> recent, or a fad, or a quirk of Swift: Josh Bloch spent over 5 pages of
> Effective Java arguing against “subclassable just in case.” That was in
> 2001, and it was old news even back then.
>
> Those looking for a more detailed analysis of the problems caused by APIs
> allowing inheritance without designing for it should read his analysis.
> It’s 15 years old, it’s Java, but it still stands. (He even gives
> instructions toward the end for simulating something very much like the
> here-proposed “sealed” in Java using package-private initializers.) It’s
> item 15 in the book, “Design and document for inheritance or else prohibit
> it.”
>
> Cheers,
>
> Paul
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> 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 proposal won’t turn bad API designers into good ones. Crappy 
APIs are still going to be crappy with or without this. In the immortal quote 
apparently due to Lawrence Flon: “There is not now, nor has there ever been, 
nor will there ever be, any programming language in which it is the least bit 
difficult to write bad code.”

The justification for this proposal is all about supporting the people who are 
working to design library APIs right, and about maintaining consistency with 
the design philosophy of Swift. To wit: in Swift, where there’s a default 
choice, it’s the safe one; where there’s a consequential design decision, it’s 
explicit.

Rod Brown hit the crux of it: sealed → open is safe for existing API clients, 
but open → sealed is a breaking change. “Sealed” is thus the safer choice, and 
“open” is a consequential design decision. Given the general precedent and 
philosophy of Swift, competent API designers might reasonably be taken aback 
that open is the default. In fact, given the habit Swift encourages of leaning 
on compiler verification, this is a potential source of designer error.

• • •

For those who think that discouraging inheritance by default is something 
recent, or a fad, or a quirk of Swift: Josh Bloch spent over 5 pages of 
Effective Java arguing against “subclassable just in case.” That was in 2001, 
and it was old news even back then.

Those looking for a more detailed analysis of the problems caused by APIs 
allowing inheritance without designing for it should read his analysis. It’s 15 
years old, it’s Java, but it still stands. (He even gives instructions toward 
the end for simulating something very much like the here-proposed “sealed” in 
Java using package-private initializers.) It’s item 15 in the book, “Design and 
document for inheritance or else prohibit it.”

Cheers,

Paul

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

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

[Rod Brown via swift-evolution]

> 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 being the cause, but it is one of those things like me giving you $5 
> or giving you $10 and later taking back $5.  As humans we are loss averse so 
> we devise strategies to hide the loss from ourselves.

I completely disagree with this.

 Not providing someone something due to risk of breakage is not the same thing 
as “giving it and taking it away”. We don’t build bridges out of spare parts 
and tell people “We build it but we expect it to break at some stage, so use 
with caution.” You either build it correctly, or you don’t let people cross the 
bridge. At All.

This isn’t about “loss averse”. This is about risk management.

Where does the line lie on risk? That’s ultimately something the core team will 
have to decide.




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

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

[Xiaodi Wu via swift-evolution]

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: ...; case c: ... }`, my condition `c` is
really `!a && !b && c`. With more flexible control flow within a switch
statement, reasoning about what cases are matched by any particular
condition after the first becomes increasingly difficult.

On Sun, Jul 10, 2016 at 9:27 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 switch statement's control flow transfer suite by
> introducing continue. Doing so provides functionality that a large
> portion of newer developers expect from (but do not get from) fallthrough.
> 
> Motivation
>
> Swift's fallthrough statement means "continue by executing the code
> defined in the next case clause". It has at least one solid use-case, which
> is demonstrated in this example
> 
>
> Swift Evolution discussed removing fallthrough on-list in early December
>  
> We
> came to the consensus that fallthroughoffers sufficient utility to retain
> the feature in the language:
>
> The
> Problem with Fallthrough.
>
> In Swift, fallthrough does not mean: "execute this case and then continue
> pattern matching", which is what many naive users expect. Given the
> following code where x is 5, they anticipate the function to print "5"
> and then "anything else". This is wrong. Swift prints "5" and then "6".
>
> func test(x : Int) {
> switch x {
> case 5:
> print("5")
> fallthrough
> case 6:
> print("6")
> default:
> print("anything else")
> }
> }
>
> Fallthrough is better suited for situations like the following:
>
> case simple where even more subconditions hold: ... do complex things ...; 
> fallthrough
> case simple where subconditions hold: ... do other things ...; fallthrough
> case simple: ... do base things ...
>
> This example produces a sieve where the most restrictive conditions
> execute specialized code and then execute code for less restrictive
> conditions.
>
> Fallthrough *cannot* be used for situations like the following example:
>
> case specialized situation 1: ... code specific to situation 1 ...; 
> fallthrough
> case specialized situation 2: ... code specific to situation 2 ...; 
> fallthrough
> case specialized situation 3: ... code specific to situation 3 ...; 
> fallthrough
> case general: ... general code applicable as well to the three specialized 
> situations ...
>
> Those coming from C-like languages might have the insight to expect
> (wrongly, it should be noted) "5", then "6", then "anything else", which is
> what you'd get with the following flawed C-ish code, where case statements
> are missing break.
>
> int x = 5;
> switch (x) {
> case 5: NSLog(@"5"); // no break;
> case 6: NSLog(@"6"); // no break;
> default: NSLog(@"anything else");
> }
>
> Swift-style switch statements are more powerful and general than C-style
> switch statements. While I do not endorse C-style switch statements, I do
> think there's a case to be made for continue, which would mean "continue
> pattern matching". It would look like this:
>
> case specialized situation 1: ... code specific to situation 1 ...; continue
> case specialized situation 2: ... code specific to situation 2 ...; continue
> case specialized situation 3: ... code specific to situation 3 ...; continue
> case general: ... general code applicable as well to the three specialized 
> situations ...
>
> In this example, code that matched general might execute any of the three
> specialized subconditions as well but would not have to fall through each
> case. So if a pattern matched scenarios 1 and 3, it would execute those
> cases and the general case, but not scenario 2.
>
> The
> advantages of continue
>
>- If adopted, continue allows code to execute multiple matching
>patterns
>- It naturally reduces code redundancy where fallthrough cannot be
>used but code applies to multiple cases (such as the 1, 3, and general
>example above).
>- It uses an existing control flow transfer keyword, using it in a
>reasonably 

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

[Taras Zakharko via swift-evolution]

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 considered for Swift 3.
> 
> -- E
> 
> Pitch: Introduce continue to Switch Statements
> 
>  
> Introduction
> 
> This pitch completes the switch statement's control flow transfer suite by 
> introducing continue. Doing so provides functionality that a large portion of 
> newer developers expect from (but do not get from) fallthrough.
> 
>  
> Motivation
> 
> Swift's fallthrough statement means "continue by executing the code defined 
> in the next case clause". It has at least one solid use-case, which is 
> demonstrated in this example 
> 
> Swift Evolution discussed removing fallthrough on-list in early December 
>  
> We came to the consensus that fallthroughoffers sufficient utility to retain 
> the feature in the language:
> 
>  
> The
>  Problem with Fallthrough.
> 
> In Swift, fallthrough does not mean: "execute this case and then continue 
> pattern matching", which is what many naive users expect. Given the following 
> code where x is 5, they anticipate the function to print "5" and then 
> "anything else". This is wrong. Swift prints "5" and then "6".
> 
> func test(x : Int) {
> switch x {
> case 5:
> print("5")
> fallthrough
> case 6:
> print("6")
> default:
> print("anything else")
> }
> }
> Fallthrough is better suited for situations like the following:
> 
> case simple where even more subconditions hold: ... do complex things ...; 
> fallthrough
> case simple where subconditions hold: ... do other things ...; fallthrough
> case simple: ... do base things ...
> This example produces a sieve where the most restrictive conditions execute 
> specialized code and then execute code for less restrictive conditions.
> 
> Fallthrough cannot be used for situations like the following example:
> 
> case specialized situation 1: ... code specific to situation 1 ...; 
> fallthrough
> case specialized situation 2: ... code specific to situation 2 ...; 
> fallthrough
> case specialized situation 3: ... code specific to situation 3 ...; 
> fallthrough
> case general: ... general code applicable as well to the three specialized 
> situations ...
> Those coming from C-like languages might have the insight to expect (wrongly, 
> it should be noted) "5", then "6", then "anything else", which is what you'd 
> get with the following flawed C-ish code, where case statements are missing 
> break.
> 
> int x = 5;
> switch (x) {
> case 5: NSLog(@"5"); // no break;
> case 6: NSLog(@"6"); // no break;
> default: NSLog(@"anything else");
> }
> Swift-style switch statements are more powerful and general than C-style 
> switch statements. While I do not endorse C-style switch statements, I do 
> think there's a case to be made for continue, which would mean "continue 
> pattern matching". It would look like this:
> 
> case specialized situation 1: ... code specific to situation 1 ...; continue
> case specialized situation 2: ... code specific to situation 2 ...; continue
> case specialized situation 3: ... code specific to situation 3 ...; continue
> case general: ... general code applicable as well to the three specialized 
> situations ...
> In this example, code that matched general might execute any of the three 
> specialized subconditions as well but would not have to fall through each 
> case. So if a pattern matched scenarios 1 and 3, it would execute those cases 
> and the general case, but not scenario 2.
> 
>  
> The
>  advantages of continue
> 
> If adopted, continue allows code to execute multiple matching patterns
> It naturally reduces code redundancy where fallthrough cannot be used but 
> code applies to multiple cases (such as the 1, 3, and general example above).
> It uses an existing control flow transfer keyword, using it in a reasonably 
> harmonious application that isn't that far out of step with how the keyword 
> is used in other parts of the language.
>  
> Detailed
>  Design
> 
> In the current design, switch statements support subset of control flow 
> transfer:
> 
> control-transfer-statement → break-statement
> control-transfer-statement → fallthrough-statement
> 

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

[Jonathan Hull via swift-evolution]

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

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 being 
the cause, but it is one of those things like me giving you $5 or giving you 
$10 and later taking back $5.  As humans we are loss averse so we devise 
strategies to hide the loss from ourselves.


> That said, I actually think you have a good point however that “sealed” 
> should be able to be overridden, either in a patch capacity or an “unsafe” 
> capacity. Should this become final at a later point, you have acknowledged 
> you know this will be unsafe and are willing to take this risk to get the job 
> done. This is opt-in risk.
> 
> Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just 
> have a keyword for “Open” as an access level, and if you subclass or override 
> things that are not “open” from other modules, you must mark unsafe.
> 
> I think this is a decent compromise: We allow potential to patch, but 
> discourage without acknowledgement of the risk. Allow Final and Open to be 
> declarative.

Pretty much, but it is important IMHO to separate this from access levels.  
They need to be orthogonal concepts or it will be confusing (e.g. why are 
structs “public” but classes “open”?).  

The default in that case would actually be ‘sealed internal(open)’ which would 
suck to type repeatedly, but you won’t have to because it is the default.  The 
thing you would type often would be ‘public open’, which is shorter than the 
new keywords in the proposal (and consistent for both classes and methods 
instead of learning different words)

I think we basically agree overall.

Thanks,
Jon


> 
> - Rod
> 
> 
> 
>> On 11 Jul 2016, at 11:05 AM, Jonathan Hull > > wrote:
>> 
>> @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 responsible).  There 
>> are other options. I grew up watching enough Star Trek that I don’t believe 
>> in no win scenarios.
>> 
>> I still think my compromise is the best solution.  3 levels: Open, Sealed, 
>> Final.  The difference is that sealed can be overridden with a compiler 
>> warning and use of “unsafe” keyword, but final can’t be overridden.  That 
>> way the user is acknowledging that they are doing something which isn’t 
>> supported in the context which they are doing it… but it doesn’t completely 
>> prevent it by default.  Opt-out safety.  (Yes you lose some compiler 
>> optimizations in the default case, but that was premature optimization 
>> anyway).
>> 
>> As for the interaction with public/internal/etc… that should be explicit.  
>> This proposal confuses and intermingles them.  You should just be able to 
>> say ‘public final internal(open)’ or some other syntax which lets you 
>> express the same sentiment.  (The above says the class/method is public and 
>> final, but internally it is open.)
>> 
>> I am not saying that we shouldn’t solve these issues.  I am saying this 
>> proposal:
>> 1) Isn’t easily discoverable.
>> 2) Requires communication between different parties (author and user) which 
>> slows iteration cycles to weeks or months (vs the usual minutes)
>> 3) Conflates/mixes the ideas of access level and subclass-ability
>> 4) Makes way too many separate changes in a single proposal: New idea of 
>> “sealed”, new default, replaces ‘public’ in some cases but not others, new 
>> keywords (which everyone wants to change), etc…
>> 5) Has structural problems which mean that it won’t actually increase 
>> thoughtfulness
>> 6) Makes app developers extremely dependent on framework authors (and those 
>> author’s schedules)
>> 7) Will require us to patch/fix it later, but that will be difficult due to 
>> optimizations/assumptions of finality.
>> 8) Will cause unnecessary pain for both framework authors and users of 
>> frameworks
>> 
>> We would be foolish to accept this proposal without planning for the 
>> inevitable escape hatch.  We will need it, and if we don’t plan for it, it 
>> will break everything when we are forced to fix it in Swift 4/5.  Anything 
>> else is idealistic to the point of ignoring real-world use/behavior.
>> 
>> As I said before, this type of thinking: “If we just make things more 
>> difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
>> Java. 

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

[Erica Sadun via swift-evolution]

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 switch statement's control flow transfer suite by 
introducing continue. Doing so provides functionality that a large portion of 
newer developers expect from (but do not get from) fallthrough.

 
Motivation

Swift's fallthrough statement means "continue by executing the code defined in 
the next case clause". It has at least one solid use-case, which is 
demonstrated in this example 

Swift Evolution discussed removing fallthrough on-list in early December 
 
We came to the consensus that fallthroughoffers sufficient utility to retain 
the feature in the language:

 
The
 Problem with Fallthrough.

In Swift, fallthrough does not mean: "execute this case and then continue 
pattern matching", which is what many naive users expect. Given the following 
code where x is 5, they anticipate the function to print "5" and then "anything 
else". This is wrong. Swift prints "5" and then "6".

func test(x : Int) {
switch x {
case 5:
print("5")
fallthrough
case 6:
print("6")
default:
print("anything else")
}
}
Fallthrough is better suited for situations like the following:

case simple where even more subconditions hold: ... do complex things ...; 
fallthrough
case simple where subconditions hold: ... do other things ...; fallthrough
case simple: ... do base things ...
This example produces a sieve where the most restrictive conditions execute 
specialized code and then execute code for less restrictive conditions.

Fallthrough cannot be used for situations like the following example:

case specialized situation 1: ... code specific to situation 1 ...; fallthrough
case specialized situation 2: ... code specific to situation 2 ...; fallthrough
case specialized situation 3: ... code specific to situation 3 ...; fallthrough
case general: ... general code applicable as well to the three specialized 
situations ...
Those coming from C-like languages might have the insight to expect (wrongly, 
it should be noted) "5", then "6", then "anything else", which is what you'd 
get with the following flawed C-ish code, where case statements are missing 
break.

int x = 5;
switch (x) {
case 5: NSLog(@"5"); // no break;
case 6: NSLog(@"6"); // no break;
default: NSLog(@"anything else");
}
Swift-style switch statements are more powerful and general than C-style switch 
statements. While I do not endorse C-style switch statements, I do think 
there's a case to be made for continue, which would mean "continue pattern 
matching". It would look like this:

case specialized situation 1: ... code specific to situation 1 ...; continue
case specialized situation 2: ... code specific to situation 2 ...; continue
case specialized situation 3: ... code specific to situation 3 ...; continue
case general: ... general code applicable as well to the three specialized 
situations ...
In this example, code that matched general might execute any of the three 
specialized subconditions as well but would not have to fall through each case. 
So if a pattern matched scenarios 1 and 3, it would execute those cases and the 
general case, but not scenario 2.

 
The
 advantages of continue

If adopted, continue allows code to execute multiple matching patterns
It naturally reduces code redundancy where fallthrough cannot be used but code 
applies to multiple cases (such as the 1, 3, and general example above).
It uses an existing control flow transfer keyword, using it in a reasonably 
harmonious application that isn't that far out of step with how the keyword is 
used in other parts of the language.
 
Detailed
 Design

In the current design, switch statements support subset of control flow 
transfer:

control-transfer-statement → break-statement
control-transfer-statement → fallthrough-statement
control-transfer-statement → return-statement
control-transfer-statement → throw-statement
Notably missing is "continue", which this proposal would adopt.

control-transfer-statement → continue-statement
The definition of continue in a switch statement would mean "after executing 
the previous statements in this case clause, continue pattern matching the 
remaining cases until a match or default is found.

continue could either be disallowed in 

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

[let var go via swift-evolution]

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 reasons
I can see against making public classes non-subclassable by default:

1. It is the opposite of nearly every other OOP language's behavior and the
opposite of what anyone will expect who is coming to Swift after doing any
OOP programming anywhere else. While I believe that Swift should be free to
buck the trends of other languages where there are significant advantages,
changing something this fundamental will introduce a new learning curve for
even experienced programmers. The advantages better be significant,
otherwise you are introducing a frustrating quirk into the language without
any great benefit in exchange. But the advantages of default
non-subclassability are marginal at best. Whatever advantage there is can
be achieved by making it opt-in using a 'sealed' keywrod, instead of by
making it the default.

2. The motivation seems to be that it will force better API design. On
average, I can't believe that it will. Assume that there are two kinds of
developers: Those that make careful decisions about their API design and
those that don't. The ones that make careful decisions about their API
design will continue to do so - I don't see any significant improvement to
their code by making non-subclassability the default. The developers who
don't make careful design decisions will just go with the default - in this
case they will just leave the default in place, and their public classes
will not be subclassable. That doesn't improve anything, it just makes
sloppy, poorly written code harder to fix in the off-chance that you are
stuck working with it. In other words, quality will not improve, but
productivity will suffer, because it will be harder to develop workarounds
for the problems that will inevitably appear in even the best-designed APIs.

3. It is a bad interpretation of the stated goal that Swift should help
developers produce "safe code." Some folks seem to believe that this means
that the language should protect people from themselves. If I am using your
API in my code and I screw it up by subclassing something that I shouldn't
have, that is somehow a language defect. It is not a language defect - it
is me being an idiot. Don't spend a lot of time trying to make a language
idiot-proof - idiots are geniuses and you will never outsmart them.
Personally, when I read that Swift helps produce "safe code", what that
means primarily is that it has a type system that helps reveal the vast
majority of bugs that would otherwise go unnoticed until runtime. In other
words, safety is related to discovering hidden flaws in the program. (Type
safety isn't the only feature that helps with this, but it is perhaps the
main one.) But this whole issue of default non-subclassability doesn't fall
into that category of "safety" at all. It doesn't help a programmer produce
safer code. The same hidden flaws will persist whether non-subclassability
is the default or not. The difference is that those same hidden flaws will
be more difficult to deal with after the fact.

To sum it up, +1 for introducing a 'sealed' keyword, but -1 for making it
the default behavior for public classes.

On Sun, Jul 10, 2016 at 12:18 PM Leonardo Pessoa via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 Folders (both come from a common class called Entry). You as a
> developer for this system will be entitled to extend from File and Entry
> freely but you can only work with Folders and its subclasses (specialised
> folders) but to this system it is important you don't subclass any type of
> folder. Without this proposal I would have to create workarounds to prevent
> you from doing that while still allowing me to subclass while playing a lot
> of finals everywhere. And so far I would have to allow you to subclass
> Folder itself (at least) but you would complain (and possibly file a bug
> report to me) because it would not be working properly because your classes
> would not benefit from the workaround. In this case, if I could subclass
> internally but prevent you from doing it, you could complain I'm not
> allowing you to do whatever you want but you wouldn't complain my code
> doesn't work properly (it does, you just won't know it).
>
> There may be several more examples but this is one I'm facing right now,
> so I can assure you it is a true example. IMO libraries are to be written
> with intention in mind and I don't think it is right to use 

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

[Rod Brown via swift-evolution]

@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 “sealed” should 
be able to be overridden, either in a patch capacity or an “unsafe” capacity. 
Should this become final at a later point, you have acknowledged you know this 
will be unsafe and are willing to take this risk to get the job done. This is 
opt-in risk.

Perhaps however this shouldn’t be “sealed” declaratively. Perhaps we just have 
a keyword for “Open” as an access level, and if you subclass or override things 
that are not “open” from other modules, you must mark unsafe.

I think this is a decent compromise: We allow potential to patch, but 
discourage without acknowledgement of the risk. Allow Final and Open to be 
declarative.

- Rod



> On 11 Jul 2016, at 11:05 AM, Jonathan Hull  wrote:
> 
> @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 responsible).  There are 
> other options. I grew up watching enough Star Trek that I don’t believe in no 
> win scenarios.
> 
> I still think my compromise is the best solution.  3 levels: Open, Sealed, 
> Final.  The difference is that sealed can be overridden with a compiler 
> warning and use of “unsafe” keyword, but final can’t be overridden.  That way 
> the user is acknowledging that they are doing something which isn’t supported 
> in the context which they are doing it… but it doesn’t completely prevent it 
> by default.  Opt-out safety.  (Yes you lose some compiler optimizations in 
> the default case, but that was premature optimization anyway).
> 
> As for the interaction with public/internal/etc… that should be explicit.  
> This proposal confuses and intermingles them.  You should just be able to say 
> ‘public final internal(open)’ or some other syntax which lets you express the 
> same sentiment.  (The above says the class/method is public and final, but 
> internally it is open.)
> 
> I am not saying that we shouldn’t solve these issues.  I am saying this 
> proposal:
> 1) Isn’t easily discoverable.
> 2) Requires communication between different parties (author and user) which 
> slows iteration cycles to weeks or months (vs the usual minutes)
> 3) Conflates/mixes the ideas of access level and subclass-ability
> 4) Makes way too many separate changes in a single proposal: New idea of 
> “sealed”, new default, replaces ‘public’ in some cases but not others, new 
> keywords (which everyone wants to change), etc…
> 5) Has structural problems which mean that it won’t actually increase 
> thoughtfulness
> 6) Makes app developers extremely dependent on framework authors (and those 
> author’s schedules)
> 7) Will require us to patch/fix it later, but that will be difficult due to 
> optimizations/assumptions of finality.
> 8) Will cause unnecessary pain for both framework authors and users of 
> frameworks
> 
> We would be foolish to accept this proposal without planning for the 
> inevitable escape hatch.  We will need it, and if we don’t plan for it, it 
> will break everything when we are forced to fix it in Swift 4/5.  Anything 
> else is idealistic to the point of ignoring real-world use/behavior.
> 
> As I said before, this type of thinking: “If we just make things more 
> difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
> Java.  The problem is, the brain doesn’t work that way, and it ultimately 
> just adds pain without being effective.  You can add forcing functions (like 
> optional unwrapping), which are annoying, but effective… but as I also 
> mentioned before this proposal doesn’t do that.  It is structurally 
> different.  It will not do what you think it does.
> 
> Thanks,
> Jon
> 
> P.S.  There is also a dangerous difference between helping the programmer 
> catch mistakes (e.g. don’t accidentally subclass the wrong method) and trying 
> to prevent them from coding in a style you disagree with.  I have been seeing 
> far to many proposals of the second variety of late.
> 
> 
>> On Jul 10, 2016, at 2:58 PM, Rod Brown > > wrote:
>> 
>> 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. I 
>> also can seal a class which has previously been open to subclassing.
>> 
>> Consider: someone builds against my framework and I do 

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

[Jordan Rose via swift-evolution]

>> 
>>> 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 legitimate concern, but IMO 
>>> it is not large enough to outweigh all of the advantages of making sealed 
>>> the default.  
>> What are your thoughts on an ability for a way to force unseal a class that 
>> does need to be fixed, even if its temporary?
>> 
>> Something like:
>> 
>> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits 
>> a scary compiler warning
>> }
>> 
>> Does that even seem feasible/possible, much less reasonable…?
>> Though it would have to be a perhaps separate discussion, this comes to my 
>> mind as becoming necessary down the road, but maybe I’m wrong...
> 
> I'm not opposed to something like this in principle, but I'm not sure how it 
> would work in practice.  There was some discussion of something along these 
> lines on the list at one point (I think Joe Groff had some ideas).  However, 
> I don't think this is possible if the optimizer takes advantage of the sealed 
> status when the library is compiled.  I'll leave it to the compiler experts 
> to comment further on feasibility.  

My technical analysis: It’s certainly implementable to have the optimizer not 
take advantage of the sealed status, and to allow some sort of 
“unsafe-break-the-seal” syntax. We’d have to be sure that anything that “can’t 
possibly happen without external subclassing” still at least generates a 
deterministic trap rather than memory corruption, but that’s probably doable.

(I’ll leave it at that, without trying to argue a particular side.)


>> 
>>> I have seen some comments about nontrivial complexity in Apple’s frameworks 
>>> caused by apps subclassing where they should not have (i.e. classes that 
>>> would be sealed if it were possible in Objective-C).  This is extremely 
>>> unfortunate and it impacts everyone on Apple’s platforms.
>>> 
>>> I wish I had links handy for you, but I don’t recall exactly where or when 
>>> this was mentioned and don’t have time to dig them up right now.
>> I see, thats reasonable… if those links are available somewhere I would 
>> definitely like to see them, it would be a good education for me…
> 
> IIRC like Jordan Rose may have made some comments along these lines either on 
> list or on Twitter if you want to search, but that is a fuzzy memory and 
> could easily be wrong.  :)

I don’t have anything handy (partially because some of it isn’t public 
knowledge), but it’s a well-known phenomenon within Apple that new OSs break 
third-party apps in strange ways because they are relying on being able to 
swizzle a non-public selector, or even on its existence. I’ll admit I don’t 
hear as much about intrusive subclassing, but that doesn’t mean Apple hasn’t 
made changes that assume no one subclasses a particular class.

[For anyone who doesn’t know the term “method swizzling”: Objective-C allows 
you to replace a class’s implementation of a method at run-time, regardless of 
where the class or the replacement is defined.]

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

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 UINavigationController methods statically, and 
bypass any subclass’s methods, thereby breaking applications. Should app apps 
have to be rebuilt to work with iOS 12 simply because Apple shipped a new 
version of UIKit? This is illogical. You will *break* things by finalising 
after the fact. Swift, being about safety, needs to deal with this safely.


> On 11 Jul 2016, at 9:13 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> 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 essence of this way of thinking is "I fear the reaction of my users when 
> I take something away from them… so I have to deny them those options right 
> from start".
> 
> I've no statistics (there's a general lack of facts all over the place…), but 
> I don't thing the majority of todays and future libraries are build with a 
> strictly planned top-down approach and guarantees about API-stability. 
> Nowadays things are much more spontaneous, and the strict rules and limits 
> some people here want to force upon others would most likely decrease the joy 
> in playing with the language and start experiments in it.
> 
> There is only a very small number of Swift-developers writing frameworks that 
> are used on a large scale basis, and even if many people in this group vote 
> for limiting defaults, the focus should be on the majority:
> When I come to the conclusion that a set of classes in a project could be 
> useful somewhere else, my problem is not fear of future API changes — it is 
> the daunting task of having to sprinkle "public" all over the place.
> Sealing classes makes proper code reuse a more tedious job, and I want Swift 
> to stay fun rather than become a playground for sticklers for order.

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

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

[Daniel Steinberg via swift-evolution]

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 proposal that examines whether it should be the default?

Best,

Daniel

> On Jul 10, 2016, at 8:49 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> 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 
>>> dynamically-dispatched 'init(context:)’, because they don’t have access to 
>>> the internal ModelContext.
>> 
>> Shouldn't Swift allow this? Wouldn't it be better if we found a different 
>> way to handle this than a brute force "you shall only subclass if I think 
>> you should"? Is that really an impossible cause that is worth us going 
>> completely the opposite direction of most programming languages?
> 
> There is no way to implement the required initializer from outside the 
> module, because it uses an internal type, so what we’re looking for is that 
> any subclasses from outside the module will never have the required 
> initializer invoked on them. I suppose it would still be safe to allow a 
> subclass from outside the module that did not provide any of its own 
> initializers, but that seems like an even more complicated rule.
> 
> (It’s not sufficient to say that the dynamic initializers would just trap at 
> run-time, because it’s possible that the base class has no public 
> initializers.)
> 
>> 
>> Can you tell me why the onus should not be on you, on library authors, to 
>> use final or an equivalent keyword to indicate no subclassing is allowed and 
>> thus make this intentional?
>> 
>> I am really not sold on why classes should not be subclassable by default. 
>> Not all classes suffer of the problem you mention and for those cases you 
>> should be able to express your intention explicitly. I am quite against this 
>> being a compiler default.
> 
> I admit that this use case says nothing about whether “sealed” should be the 
> default or just available.
> 
>> I think that security by ignorance, which is what automagically enforced 
>> rules tend to produce over time, does have some side effects.
> 
> This isn’t really a security issue; it’s a compiler-aided correctness issue. 
> I’ll go more into that in my other email.
> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jordan Rose via swift-evolution]

> 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 here, where 
>> all of the subclasses are within a single module, but they are all public. 
>> The class also has a required initializer for dynamic construction, so that 
>> they could write something like this:
>> internal struct ModelContext { /*…*/ }
>> public class ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>>   // …
>> }
>> public class SimpleModel: ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>> }
>> public class MoreComplicatedModel: ModelBase { /*…*/ }
>> // (within some other type)
>> public func instantiateModelObject(_ type: Model) -> Model 
>> {
>>   return type.init(context: self.context)
>> }
>> That is, a public entry point calls a required initializer with an internal 
>> argument type. This is the only way to instantiate Model objects, and the 
>> internal context type doesn’t leak out into the public API.
>> Of course, Swift doesn’t allow this. If someone outside of the module 
>> subclasses ModelBase, there’s no way for them to provide the 
>> dynamically-dispatched 'init(context:)’, because they don’t have access to 
>> the internal ModelContext. The author of the library has to make the 
>> required initializers public, and either set the ModelContext separately or 
>> make it public as well. Even though no one outside the module should be 
>> using these APIs.
> 
> Can you remind us why does Swift need required initializers to have the same 
> access as the containing class?
> 
> Having only package-internal constructors in the public base class is the 
> usual pattern for exporting a sealed class hierarchy in some other languages, 
> like Java.

Sure. A required initializer is one that will be invoked on an unknown subclass 
of the type, as in the instantiateModelObject method above. That means that it 
must be present on all subclasses, because it’s generally impossible to prove 
that a particular subclass will not be passed to instantiateModelObject.

Swift currently doesn’t allow this at all, but we could imagine making it a 
run-time error instead of a compile-time error, i.e. if instantiateModelObject 
is called on a class that doesn’t provide its own implementation of 
init(context:), the program would trap. That’d be giving up some 
compiler-provided safety for run-time flexibility, which can certainly be 
desirable.

However, this is just the tip of the iceberg. In the implementation of the 
subclass, there has to be a call to one of the superclass's initializers. If 
all of the superclass’s initializers are non-public, then there’s no way to 
write your own initializer. (This is actually true in Swift today.) This isn’t 
quite the same as sealed-by-default because the subclass could just inherit the 
superclass’s initializers, but it’s very close: the only way to instantiate 
such a class would be through a required initializer, which you couldn’t 
customize.

In that sense, Swift already has something very similar to sealed-by-default, 
which just doesn’t work very well in the particular use case where you also 
need to use dynamic initialization.

Jordan

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

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

[Jonathan Hull via swift-evolution]

@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 responsible).  There are 
other options. I grew up watching enough Star Trek that I don’t believe in no 
win scenarios.

I still think my compromise is the best solution.  3 levels: Open, Sealed, 
Final.  The difference is that sealed can be overridden with a compiler warning 
and use of “unsafe” keyword, but final can’t be overridden.  That way the user 
is acknowledging that they are doing something which isn’t supported in the 
context which they are doing it… but it doesn’t completely prevent it by 
default.  Opt-out safety.  (Yes you lose some compiler optimizations in the 
default case, but that was premature optimization anyway).

As for the interaction with public/internal/etc… that should be explicit.  This 
proposal confuses and intermingles them.  You should just be able to say 
‘public final internal(open)’ or some other syntax which lets you express the 
same sentiment.  (The above says the class/method is public and final, but 
internally it is open.)

I am not saying that we shouldn’t solve these issues.  I am saying this 
proposal:
1) Isn’t easily discoverable.
2) Requires communication between different parties (author and user) which 
slows iteration cycles to weeks or months (vs the usual minutes)
3) Conflates/mixes the ideas of access level and subclass-ability
4) Makes way too many separate changes in a single proposal: New idea of 
“sealed”, new default, replaces ‘public’ in some cases but not others, new 
keywords (which everyone wants to change), etc…
5) Has structural problems which mean that it won’t actually increase 
thoughtfulness
6) Makes app developers extremely dependent on framework authors (and those 
author’s schedules)
7) Will require us to patch/fix it later, but that will be difficult due to 
optimizations/assumptions of finality.
8) Will cause unnecessary pain for both framework authors and users of 
frameworks

We would be foolish to accept this proposal without planning for the inevitable 
escape hatch.  We will need it, and if we don’t plan for it, it will break 
everything when we are forced to fix it in Swift 4/5.  Anything else is 
idealistic to the point of ignoring real-world use/behavior.

As I said before, this type of thinking: “If we just make things more 
difficult, it will encourage awareness” is what leads to the DMV, TSA, and 
Java.  The problem is, the brain doesn’t work that way, and it ultimately just 
adds pain without being effective.  You can add forcing functions (like 
optional unwrapping), which are annoying, but effective… but as I also 
mentioned before this proposal doesn’t do that.  It is structurally different.  
It will not do what you think it does.

Thanks,
Jon

P.S.  There is also a dangerous difference between helping the programmer catch 
mistakes (e.g. don’t accidentally subclass the wrong method) and trying to 
prevent them from coding in a style you disagree with.  I have been seeing far 
to many proposals of the second variety of late.


> On Jul 10, 2016, at 2:58 PM, Rod Brown  wrote:
> 
> 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. I also 
> can seal a class which has previously been open to subclassing.
> 
> Consider: someone builds against my framework and I do nothing, and they 
> subclass my classes. Then later I come through and mark the classes as 
> "Sealed". What should we do with those classes that are subclassing my 
> classes? Nothing. I can't. I permitted access and now I'm beholden to that 
> access level.
> 
> On the other hand, opening up access levels gradually has no such issues. 
> Users of my class can't subclass, and then they can. They just have another 
> tool in the bag now.
> 
> If you want a default, it should be one you can reverse later. Your default 
> should not be the most restrictive.
> 
> Whilst I agree with most of your points, this core concept seems to trump 
> them to my mind.
> 
> - Rod
> 
> On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution 
> > wrote:
> 
>> Please stop saying that this proposal will bring more consideration to the 
>> design of libraries.  It isn’t true.  I haven’t even seen an argument for 
>> why it would be true, it is just taken for granted that it is true.
>> 
>> As I mentioned in another post, this is structurally very different from 
>> things like ‘if-let’ and optionals.  Optionals force the user to consider 
>> their 

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

[Jordan Rose via swift-evolution]

> 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 
>> dynamically-dispatched 'init(context:)’, because they don’t have access to 
>> the internal ModelContext.
> 
> Shouldn't Swift allow this? Wouldn't it be better if we found a different way 
> to handle this than a brute force "you shall only subclass if I think you 
> should"? Is that really an impossible cause that is worth us going completely 
> the opposite direction of most programming languages?

There is no way to implement the required initializer from outside the module, 
because it uses an internal type, so what we’re looking for is that any 
subclasses from outside the module will never have the required initializer 
invoked on them. I suppose it would still be safe to allow a subclass from 
outside the module that did not provide any of its own initializers, but that 
seems like an even more complicated rule.

(It’s not sufficient to say that the dynamic initializers would just trap at 
run-time, because it’s possible that the base class has no public initializers.)

> 
> Can you tell me why the onus should not be on you, on library authors, to use 
> final or an equivalent keyword to indicate no subclassing is allowed and thus 
> make this intentional?
> 
> I am really not sold on why classes should not be subclassable by default. 
> Not all classes suffer of the problem you mention and for those cases you 
> should be able to express your intention explicitly. I am quite against this 
> being a compiler default.

I admit that this use case says nothing about whether “sealed” should be the 
default or just available.

> I think that security by ignorance, which is what automagically enforced 
> rules tend to produce over time, does have some side effects.

This isn’t really a security issue; it’s a compiler-aided correctness issue. 
I’ll go more into that in my other email.

Jordan

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

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

[Jordan Rose via swift-evolution]

> 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 
> > wrote:
> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>>  
>> 
>>  ]
>> 
>> John has done a tremendous job supporting this proposal; the position he’s 
>> articulated very closely matches mine. Thank you to both John and Javier. 
>> 
>> 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 here, where 
>> all of the subclasses are within a single module, but they are all public. 
>> The class also has a required initializer for dynamic construction, so that 
>> they could write something like this:
>> 
>> internal struct ModelContext { /*…*/ }
>> 
>> public class ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>>   // …
>> }
>> public class SimpleModel: ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>> }
>> public class MoreComplicatedModel: ModelBase { /*…*/ }
>> 
>> // (within some other type)
>> public func instantiateModelObject(_ type: Model) -> Model 
>> {
>>   return type.init(context: self.context)
>> }
>> 
>> That is, a public entry point calls a required initializer with an internal 
>> argument type. This is the only way to instantiate Model objects, and the 
>> internal context type doesn’t leak out into the public API.
> 
> Then could it be that in the end it is the entire scaffolding that is poorly 
> structured and in need of fixing, rather than altering the language to make 
> the scaffolding work?

I’m afraid it isn’t my codebase, so I can’t speak to this directly, but I don’t 
see anything wrong with this pattern. Dynamic initialization is useful, and 
internal, component-specific context is hardly uncommon; if the library used 
either of these alone we would likely have no problem with it. Two features not 
composing well does sometimes indicate a flaw in the design.

Jordan

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

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

[Shawn Erickson via swift-evolution]

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

[G B via swift-evolution]

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 with that in mind.  It took me a long time to 
get used to not using them in Python, now I’m getting used to using them again 
in Swift.  Swift has a long life ahead of it, and there are going to be plenty 
of places where the syntax is going to become inconsistent in the service of 
supporting new features.  Now is when we set the starting point though and try 
to set ourselves up in a way that requires a minimum of syntax goofs in the 
future.


—=Philosophy=— 

As philosophical backdrop, here’s the link on removing braces in the “commonly 
rejected proposals” section:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"There is not in fact an emphasis on conciseness. This has been repeated many 
times by the swift team. Conciseness is not a goal of Swift, but expressiveness 
absolutely is. Braces are a well-understood and simple way to express the 
notion of a scope/closure.”

and another edited as suggested by Chris Lattner:
"'Be like C' isn't a goal either of course, but when deciding between two 
alternatives that have no compelling arguments either way, picking the one that 
is most familiar to programmers in the extended C family is a good idea."


So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.




—=In C `cases` Aren’t Scopes, in Swift They Are=—

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
  case 3:
let y=5
print(x," ",y)

  case 5:
print("Two",x,"s”)

  default:
print(“default")
}


This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
  case 3:
int y=5;
printf("%d %d",x,y);
break;

  case 5:
printf("Two %d s",x);
break;

  default:
printf(“default");
}


This code fails.  C gives me an error pointing at `int y=5;` complaining that 
it expected an expression there.  C++ gives me an error that it can’t jump to 
`case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly braces, 
creating a local scope:

int x=5;
switch (x) {
  case 3:  {
int y=5;
printf("%d %d",x,y);
break;
  }

  case 5:
printf("Two %d s",x);
break;

  default:
printf("default");
}

This code compiles fine in both C and C++.  A new scope has been delimited and 
created, and `y` only exists in that scope.


So, by both criteria 1) and 3), Swift should be using braces on `case` 
statements.  Each case is a scope unto itself, and the extended C family of 
languages would require braces in that event.





—=Conciseness, Ugliness and Nested Braces=—

Conciseness is not an emphasis of Swift, but even if it were then this is not a 
particularly in-concise change to the syntax.  The suggestion here is to remove 
one punctuation mark and add two for a net gain of 1 character.  This doesn’t 
strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use.  Each of these 
seems to focus on opposite situations.  The ugliness is when there is only one 
line per case, the ease of use challenge is when there are many and the 
developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective.  Ease of use, in part, depends on 
habits.  In both cases, however, I’d argue that the aesthetically preferable 
design, and the method least likely to introduce errors, is the one that is 
most consistent with the rest of the language.  Things tend to be uglier when 
they stand out as unusual, and habits force us to follow patterns, introducing 
errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3  { print(“Three”) }
else if x = 5 { print(“Five”) }
else  { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
  get { return _x }
  set { _x = newValue }
}


Aesthetically, is it less ugly to have some scopes require braces and others 
not?  I really thought the square bracket messaging syntax of Obj-C was ugly 
until I got used to it because square brackets were for subscripting and looked 
“heavy” for method calls.  

From an ease of use perspective, it is more likely to forget to add a closing 
brace when braces are used everywhere, or to accidentally add one in the one 
place they aren’t?




—=What Isn’t Like C Shouldn’t Look Like C=—

There’s also the point that `switch` statements in Swift aren’t the same as 
those 

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

[Tino Heth via swift-evolution]

> 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 think the feature would be 
needed… but wait:
How could you write it then? Do I have a wrong interpretation of "needed", or 
did you write this thing in an apocalyptic future? ;-)

> As I said, a concrete and real example. But I haven't seen anyone give the 
> slightest concrete technical reason not to approve it and please don't come 
> saying fix bugs in a library by subclassing because that's not what 
> subclassing is for. That is a misuse of object orientation in whichever 
> language you're working with.
At least there are many real (at least I think so) examples of problems that 
could be solved because sealed isn't the default now…
But as I said in another message:
All of this is not about technical reasons, but only about personal preference 
— and my preference is to have fun writing software, instead of struggling with 
bureaucracy.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[James Froggatt via swift-evolution]

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 access.

From James F

On 10 Jul 2016, at 23:57, Brent Royal-Gordon  wrote:

>> 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 suitable, since it implies the possibility 
>> to set the value.
> 
> Can you show us an example of the current syntax and your proposed 
> replacement? I'm not sure what you actually mean by "use colons".
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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 essence of this way of thinking is "I fear the reaction of my users when I 
take something away from them… so I have to deny them those options right from 
start".

I've no statistics (there's a general lack of facts all over the place…), but I 
don't thing the majority of todays and future libraries are build with a 
strictly planned top-down approach and guarantees about API-stability. Nowadays 
things are much more spontaneous, and the strict rules and limits some people 
here want to force upon others would most likely decrease the joy in playing 
with the language and start experiments in it.

There is only a very small number of Swift-developers writing frameworks that 
are used on a large scale basis, and even if many people in this group vote for 
limiting defaults, the focus should be on the majority:
When I come to the conclusion that a set of classes in a project could be 
useful somewhere else, my problem is not fear of future API changes — it is the 
daunting task of having to sprinkle "public" all over the place.
Sealing classes makes proper code reuse a more tedious job, and I want Swift to 
stay fun rather than become a playground for sticklers for order.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Michael Peternell via swift-evolution]

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 behavior comes 
from. And for the performance argument: there is no performance benefit of this 
proposal. I cannot prove this of course, but you'll remember my words in a year 
or so, when this proposal has been adopted and we can measure the alleged 
benefits of it. I can already see how this "feature" will be rolled back for 
Swift 4 ;)

I'm not against change in general. I think going from Swift 1 to Swift 2 was a 
big improvement. Swift 2 to Swift 3 is overall okay, but it gets worse by 
introducing things like NoReturn/Never or sealed subclasses.

-Michael

> Am 11.07.2016 um 00:53 schrieb Leonardo Pessoa via swift-evolution 
> :
> 
> 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' folders: aside the basics you have smart folders, disks, remote 
> folders and so forth. They follow the same basics but some specificities will 
> vary. You can create as many different files you want but can you create a 
> new type of folder there? Same here.
> 
> Too bad my example did not convince you but subclassing to fix bugs also 
> don't convince me. I really believed this is the behaviour that leads bugs in 
> a library not to be fixed: because instead of helping improving the library 
> for everyone you fix it for yourself and let it go. The developer of the 
> library doesn't even care to fix the bug since everyone uses your subclass 
> fix or he finds out purple doing this, fixes the bug and puts a final there 
> breaking everyone's app.
> 
> L
> From: Tino Heth
> Sent: ‎10/‎07/‎2016 05:47 PM
> To: Leonardo Pessoa
> Cc: swift-evolution; Jean-Daniel Dupas
> Subject: Re: [swift-evolution] [Review] SE-0117: Default classes 
> tobenon-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 threads… I tried, but how much time should I spend searching without any 
> helpful hint?
> But let's see what we got now...
> 
>> I'm currently working on an app
> wait a minute: An app, not a library? What difference will sealed make here 
> at all?
> 
>> which will have object representations of Files and Folders (both come from 
>> a common class called Entry). You as a developer for this system will be 
>> entitled to extend from File and Entry freely but you can only work with 
>> Folders and its subclasses (specialised folders) but to this system it is 
>> important you don't subclass any type of folder. Without this proposal I 
>> would have to create workarounds to prevent you from doing that while still 
>> allowing me to subclass while playing a lot of finals everywhere. And so far 
>> I would have to allow you to subclass Folder itself (at least) but you would 
>> complain (and possibly file a bug report to me) because it would not be 
>> working properly because your classes would not benefit from the workaround. 
>> In this case, if I could subclass internally but prevent you from doing it, 
>> you could complain I'm not allowing you to do whatever you want but you 
>> wouldn't complain my code doesn't work properly (it does, you just won't 
>> know it).
> So, how many types of directories may exist that you would have to mark as 
> final? (serious question — please don't ignore it)
> I don't know about you specific model, but for me, invisible directories and 
> bundles would be all I'd be worried about — and those are basically all 
> normal folders as well…
> So, do those subclasses each have special properties? There is only a limited 
> set of metadata a directory can have, so I expect there is no need for 
> subclassing at all: Is there a special reason why it can't be a single class, 
> or an enum?
> This may all be useless advice that doesn't work for your case — but if I 
> stick with the Sasquatch-metapher, this is a very blurred picture...
> 
>> IMO libraries are to be written with intention in mind and I don't think it 
>> is right to use a library written to compose a PDF file to send an email 
>> (even if you're sending the PDF file attached, the right way to do it is by 
>> composition not subclassing).
> How is this statement connected to the proposal?
> The only way to prevent misuse of software is not to write it; and what harm 
> is done to you as the 

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

[L. Mihalkovic via swift-evolution]

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 server systems 
where code would be shared between the two sides. Currently I do that with c# 
and started experimenting with phonegap using typescript (I share Anders 
Hejlsberg's view that past a few 1000 locs javascript becomes readonly). 
If I can appreciate that as an app-only language a number of tradeoffs are not 
terribly important in the long run, I question whether the same choices are 
equally inconsequential at the other end of the scale. I took seriously that 
apple will let swift become credible on the server side, but it might require 
that this community remembers to consider both ends of the scale when helping 
shape this language. I have read a lot past discussions of the last month, and 
I do wonder where people see this language go, and more importantly where they 
want to see it go. I do hope the future of swift is not just made of apps.
Regards
(From mobile)
> On Jul 10, 2016, at 10:47 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> 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 threads… I tried, but how much time should I spend searching without any 
> helpful hint?
> But let's see what we got now...
> 
>> I'm currently working on an app
> wait a minute: An app, not a library? What difference will sealed make here 
> at all?
> 
>> which will have object representations of Files and Folders (both come from 
>> a common class called Entry). You as a developer for this system will be 
>> entitled to extend from File and Entry freely but you can only work with 
>> Folders and its subclasses (specialised folders) but to this system it is 
>> important you don't subclass any type of folder. Without this proposal I 
>> would have to create workarounds to prevent you from doing that while still 
>> allowing me to subclass while playing a lot of finals everywhere. And so far 
>> I would have to allow you to subclass Folder itself (at least) but you would 
>> complain (and possibly file a bug report to me) because it would not be 
>> working properly because your classes would not benefit from the workaround. 
>> In this case, if I could subclass internally but prevent you from doing it, 
>> you could complain I'm not allowing you to do whatever you want but you 
>> wouldn't complain my code doesn't work properly (it does, you just won't 
>> know it).
> So, how many types of directories may exist that you would have to mark as 
> final? (serious question — please don't ignore it)
> I don't know about you specific model, but for me, invisible directories and 
> bundles would be all I'd be worried about — and those are basically all 
> normal folders as well…
> So, do those subclasses each have special properties? There is only a limited 
> set of metadata a directory can have, so I expect there is no need for 
> subclassing at all: Is there a special reason why it can't be a single class, 
> or an enum?
> This may all be useless advice that doesn't work for your case — but if I 
> stick with the Sasquatch-metapher, this is a very blurred picture...
> 
>> IMO libraries are to be written with intention in mind and I don't think it 
>> is right to use a library written to compose a PDF file to send an email 
>> (even if you're sending the PDF file attached, the right way to do it is by 
>> composition not subclassing).
> How is this statement connected to the proposal?
> The only way to prevent misuse of software is not to write it; and what harm 
> is done to you as the author of a PDF-lib (btw: been there, done that — nasty 
> format ;-) if some stupid user turns your composer into Emacs?
> 
>> Additionally, someone mentioned and I went in to check about a 
>> recommendation for Java to intentionally document and enable classes to be 
>> subclasses explicitly otherwise forbid it at all and that recommendation 
>> seems to come from Oracle itself. I believe Oracle would do it to Java if it 
>> had great interest in it without consulting anyone's opinion.
> good point… Oracle is widely known for its instinctive knowledge about the 
> needs and problems of their customers — which they than tend to ignore and do 
> something different ;-) 
> 
>> About the addition to the proposal to enable force unsealing, I'm completely 
>> opposed as it is just like not having any of this protection at all (why 
>> putting a lock on the door to your house if the key is under the mat?)
> As long as we don't speak about commercial libraries, 

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

[Brent Royal-Gordon via swift-evolution]

> 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 suitable, since it implies the possibility 
> to set the value.

Can you show us an example of the current syntax and your proposed replacement? 
I'm not sure what you actually mean by "use colons".

-- 
Brent Royal-Gordon
Architechies

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

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

[Leonardo Pessoa via swift-evolution]

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' folders: aside the basics you have smart folders, disks, remote folders 
and so forth. They follow the same basics but some specificities will vary. You 
can create as many different files you want but can you create a new type of 
folder there? Same here.

Too bad my example did not convince you but subclassing to fix bugs also don't 
convince me. I really believed this is the behaviour that leads bugs in a 
library not to be fixed: because instead of helping improving the library for 
everyone you fix it for yourself and let it go. The developer of the library 
doesn't even care to fix the bug since everyone uses your subclass fix or he 
finds out purple doing this, fixes the bug and puts a final there breaking 
everyone's app.

L

-Original Message-
From: "Tino Heth" <2...@gmx.de>
Sent: ‎10/‎07/‎2016 05:47 PM
To: "Leonardo Pessoa" 
Cc: "swift-evolution" ; "Jean-Daniel Dupas" 

Subject: Re: [swift-evolution] [Review] SE-0117: Default classes 
tobenon-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 threads… I tried, but how much time should I spend searching without any 
helpful hint?
But let's see what we got now...


I'm currently working on an app 
wait a minute: An app, not a library? What difference will sealed make here at 
all?


which will have object representations of Files and Folders (both come from a 
common class called Entry). You as a developer for this system will be entitled 
to extend from File and Entry freely but you can only work with Folders and its 
subclasses (specialised folders) but to this system it is important you don't 
subclass any type of folder. Without this proposal I would have to create 
workarounds to prevent you from doing that while still allowing me to subclass 
while playing a lot of finals everywhere. And so far I would have to allow you 
to subclass Folder itself (at least) but you would complain (and possibly file 
a bug report to me) because it would not be working properly because your 
classes would not benefit from the workaround. In this case, if I could 
subclass internally but prevent you from doing it, you could complain I'm not 
allowing you to do whatever you want but you wouldn't complain my code doesn't 
work properly (it does, you just won't know it).

So, how many types of directories may exist that you would have to mark as 
final? (serious question — please don't ignore it)
I don't know about you specific model, but for me, invisible directories and 
bundles would be all I'd be worried about — and those are basically all normal 
folders as well…
So, do those subclasses each have special properties? There is only a limited 
set of metadata a directory can have, so I expect there is no need for 
subclassing at all: Is there a special reason why it can't be a single class, 
or an enum?
This may all be useless advice that doesn't work for your case — but if I stick 
with the Sasquatch-metapher, this is a very blurred picture...


IMO libraries are to be written with intention in mind and I don't think it is 
right to use a library written to compose a PDF file to send an email (even if 
you're sending the PDF file attached, the right way to do it is by composition 
not subclassing).

How is this statement connected to the proposal?
The only way to prevent misuse of software is not to write it; and what harm is 
done to you as the author of a PDF-lib (btw: been there, done that — nasty 
format ;-) if some stupid user turns your composer into Emacs?


Additionally, someone mentioned and I went in to check about a recommendation 
for Java to intentionally document and enable classes to be subclasses 
explicitly otherwise forbid it at all and that recommendation seems to come 
from Oracle itself. I believe Oracle would do it to Java if it had great 
interest in it without consulting anyone's opinion.

good point… Oracle is widely known for its instinctive knowledge about the 
needs and problems of their customers — which they than tend to ignore and do 
something different ;-) 


About the addition to the proposal to enable force unsealing, I'm completely 
opposed as it is just like not having any of this protection at all (why 
putting a lock on the door to your house if the key is under the mat?)

As long as we don't speak about commercial libraries, which are a curiosity in 
the Swift-cosmos:
There is no lock, there 

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

[Leonardo Pessoa via swift-evolution]

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 nature of the system. 
It was intended to be exactly like this and there was nothing incidental about 
them. IMO a well designed library is like an app with plugins: you're not 
entitled to do whatever you want in the app through a plugin but the app 
controls and dictates what it allows you to do.

You asked for an example where this feature would be needed and I've provided. 
As I said, a concrete and real example. But I haven't seen anyone give the 
slightest concrete technical reason not to approve it and please don't come 
saying fix bugs in a library by subclassing because that's not what subclassing 
is for. That is a misuse of object orientation in whichever language you're 
working with.

L

-Original Message-
From: "Garth Snyder via swift-evolution" 
Sent: ‎10/‎07/‎2016 05:47 PM
To: "swift-evolution" 
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
benon-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 about 
the actual pros and cons.


Leonardo Pessoa responded: ...an app which will have object representations of 
Files and Folders (both come from a common class called Entry). You [can] 
extend from File and Entry freely but...it is important you don't subclass any 
type of Folder. Without this proposal I would have to create workarounds to 
prevent you from doing that while still allowing me to subclass while playing a 
lot of finals everywhere. And so far I would have to allow you to subclass 
Folder itself (at least) but you would complain (and possibly file a bug report 
to me) because it would not be working properly because your classes would not 
benefit from the workaround. In this case, if I could subclass internally but 
prevent you from doing it, you could complain I'm not allowing you to do 
whatever you want but you wouldn't complain my code doesn't work properly (it 
does, you just won't know it).



To me, this scenario seems like an example of why the proposal should be 
rejected.


Correct me if I’m wrong, but your (Leonardo’s) narrative suggests that the 
subclassability of File and Entry is incidental. If the intent was actively to 
allow people to provide their own implementations of filesystem objects, you 
would presumably have taken whatever steps were necessary to make Folder 
subclassable as well.


This scenario ends up defining a perfectly commonplace mix of classes. Some of 
them behave reasonably when subclassed and some don’t. The question is, should 
Swift — as a matter of default policy and community style — actively push you 
to seal ALL of these classes?


No, it shouldn’t. You’d be removing the possibility of functionality that’s 
potentially useful to some clients, without gaining much in return.


A “sealed” keyword or equivalent seems plausible, but it shouldn’t be the 
default. 


Even an affirmative “sealed" feels prone to abuse, however. In this case, for 
example, I would imagine there would be considerable temptation to mark all 
objects (Entry, File, Folder, etc.) as sealed, just because Folder needs it. 
API designers (and clients!) dislike unexplained asymmetry.


Garth___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

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. I also can 
seal a class which has previously been open to subclassing.

Consider: someone builds against my framework and I do nothing, and they 
subclass my classes. Then later I come through and mark the classes as 
"Sealed". What should we do with those classes that are subclassing my classes? 
Nothing. I can't. I permitted access and now I'm beholden to that access level.

On the other hand, opening up access levels gradually has no such issues. Users 
of my class can't subclass, and then they can. They just have another tool in 
the bag now.

If you want a default, it should be one you can reverse later. Your default 
should not be the most restrictive.

Whilst I agree with most of your points, this core concept seems to trump them 
to my mind.

- Rod

> On 10 Jul. 2016, at 5:51 am, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Please stop saying that this proposal will bring more consideration to the 
> design of libraries.  It isn’t true.  I haven’t even seen an argument for why 
> it would be true, it is just taken for granted that it is true.
> 
> As I mentioned in another post, this is structurally very different from 
> things like ‘if-let’ and optionals.  Optionals force the user to consider 
> their decision in the context it is being used (i.e. as you use the 
> optional/value).  This proposal, however, does the opposite.  The effect of 
> your actions appear in the context of a completely different user.  It is 
> like sitting in a room, flipping a light switch wondering “I wonder what this 
> does?”… meanwhile the people downstairs are wondering why their lights keep 
> turning off and on”.  
> 
> You can try to test for this, but by definition library authors can only test 
> for scenarios that they have thought of.  I have often found people surprise 
> me with their use-cases.  Relying on the diligence of other programmers is 
> what leads to things like: "You always need to remember to test for zero 
> before using a pointer".  Literally the opposite of optionals!  It sounds 
> good, but at the end of the day, people are human and they WILL make 
> mistakes.  Best to either catch those mistakes in the context where they 
> happen or to mitigate the effect of it.  This proposal basically forces you 
> to feel the full effect of other people's mistakes (thinking that it will 
> discourage them from making them in the first place).
> 
> Your only real mechanism for feedback is when users of your library complain 
> to you that something that they need isn’t subclass-able.  This is the point 
> where most framework authors will actually learn that this feature/default 
> exists.  Users of a framework will learn of it slightly earlier, when they 
> find they need to subclass something, and it just isn’t possible.
> 
> 
> I would much prefer adding a ‘sealed’ keyword which library authors could use 
> to annotate things which they do not want subclassed outside of the module.  
> Or preferably, as others have suggested, allow augmentation of ‘final’ with 
> ‘public(final)' or ‘internal(final)’.
> 
> The only case where I would support ‘sealed’ by default is if there are 3 
> levels: open, sealed, final.  Final would allow 'public(final)' and 
> 'internal(final)’ to allow private subclassing inside the file/module.  
> Sealed would be the same, except it would allow the user to subclass by 
> explicitly acknowledging the risk using ‘unsafe’:  “unsafe class 
> MySubclass:SealedSuper“ and  “unsafe override func”.  Final would not allow 
> the override.
> 
> That is the case where ‘sealed’ makes sense as a default…
> 
> Thanks,
> Jon
> 
> P.S. The current proposal will only cause massive problems down the line, 
> IMHO.  We will find an escape hatch is needed, but we will have made 
> optimizations based on assumptions of finality which prevent us from easily 
> adding one.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

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 scenarios:
> 
> https://github.com/Jasdev/swift-evolution/blob/static-func-static-var/proposals/-static-func-and-static-var-func-protocol-conformance.md
> 
> Would love any feedback or edge cases I may have missed!
> -- 
> @jasdev
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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 threads… I tried, but how much time should I spend searching without any 
helpful hint?
But let's see what we got now...

> I'm currently working on an app
wait a minute: An app, not a library? What difference will sealed make here at 
all?

> which will have object representations of Files and Folders (both come from a 
> common class called Entry). You as a developer for this system will be 
> entitled to extend from File and Entry freely but you can only work with 
> Folders and its subclasses (specialised folders) but to this system it is 
> important you don't subclass any type of folder. Without this proposal I 
> would have to create workarounds to prevent you from doing that while still 
> allowing me to subclass while playing a lot of finals everywhere. And so far 
> I would have to allow you to subclass Folder itself (at least) but you would 
> complain (and possibly file a bug report to me) because it would not be 
> working properly because your classes would not benefit from the workaround. 
> In this case, if I could subclass internally but prevent you from doing it, 
> you could complain I'm not allowing you to do whatever you want but you 
> wouldn't complain my code doesn't work properly (it does, you just won't know 
> it).
So, how many types of directories may exist that you would have to mark as 
final? (serious question — please don't ignore it)
I don't know about you specific model, but for me, invisible directories and 
bundles would be all I'd be worried about — and those are basically all normal 
folders as well…
So, do those subclasses each have special properties? There is only a limited 
set of metadata a directory can have, so I expect there is no need for 
subclassing at all: Is there a special reason why it can't be a single class, 
or an enum?
This may all be useless advice that doesn't work for your case — but if I stick 
with the Sasquatch-metapher, this is a very blurred picture...

> IMO libraries are to be written with intention in mind and I don't think it 
> is right to use a library written to compose a PDF file to send an email 
> (even if you're sending the PDF file attached, the right way to do it is by 
> composition not subclassing).
How is this statement connected to the proposal?
The only way to prevent misuse of software is not to write it; and what harm is 
done to you as the author of a PDF-lib (btw: been there, done that — nasty 
format ;-) if some stupid user turns your composer into Emacs?

> Additionally, someone mentioned and I went in to check about a recommendation 
> for Java to intentionally document and enable classes to be subclasses 
> explicitly otherwise forbid it at all and that recommendation seems to come 
> from Oracle itself. I believe Oracle would do it to Java if it had great 
> interest in it without consulting anyone's opinion.
good point… Oracle is widely known for its instinctive knowledge about the 
needs and problems of their customers — which they than tend to ignore and do 
something different ;-) 

> About the addition to the proposal to enable force unsealing, I'm completely 
> opposed as it is just like not having any of this protection at all (why 
> putting a lock on the door to your house if the key is under the mat?)
As long as we don't speak about commercial libraries, which are a curiosity in 
the Swift-cosmos:
There is no lock, there is not even a door — there is only a tiny sign that 
says "please don't enter", and the worst thing that could happen if you ignore 
it is that the original owner stops doing the housework.

> If I'm not wrong at least one member of the core team already mentioned in 
> this thread this is completely aligned with the intention of the language, so 
> I think we should give it a go and stop trying to have/keep control of 
> everything we touch.
Isn't this exactly what this proposal is about? Replacing freedom with control? 
Stop trying to keep control of everything is actually a good idea in the light 
of this proposal.

I appreciate that you described your case, but it didn't do anything to 
convince me.

Tino

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

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

[Garth Snyder via swift-evolution]

> 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 
> about the actual pros and cons.

> Leonardo Pessoa responded: ...an app which will have object representations 
> of Files and Folders (both come from a common class called Entry). You [can] 
> extend from File and Entry freely but...it is important you don't subclass 
> any type of Folder. Without this proposal I would have to create workarounds 
> to prevent you from doing that while still allowing me to subclass while 
> playing a lot of finals everywhere. And so far I would have to allow you to 
> subclass Folder itself (at least) but you would complain (and possibly file a 
> bug report to me) because it would not be working properly because your 
> classes would not benefit from the workaround. In this case, if I could 
> subclass internally but prevent you from doing it, you could complain I'm not 
> allowing you to do whatever you want but you wouldn't complain my code 
> doesn't work properly (it does, you just won't know it).


To me, this scenario seems like an example of why the proposal should be 
rejected.

Correct me if I’m wrong, but your (Leonardo’s) narrative suggests that the 
subclassability of File and Entry is incidental. If the intent was actively to 
allow people to provide their own implementations of filesystem objects, you 
would presumably have taken whatever steps were necessary to make Folder 
subclassable as well.

This scenario ends up defining a perfectly commonplace mix of classes. Some of 
them behave reasonably when subclassed and some don’t. The question is, should 
Swift — as a matter of default policy and community style — actively push you 
to seal ALL of these classes?

No, it shouldn’t. You’d be removing the possibility of functionality that’s 
potentially useful to some clients, without gaining much in return.

A “sealed” keyword or equivalent seems plausible, but it shouldn’t be the 
default. 

Even an affirmative “sealed" feels prone to abuse, however. In this case, for 
example, I would imagine there would be considerable temptation to mark all 
objects (Entry, File, Folder, etc.) as sealed, just because Folder needs it. 
API designers (and clients!) dislike unexplained asymmetry.

Garth

___
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

[Dennis De Mars via swift-evolution]

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 modern languages, Swift 
included, is the use of curly braces everywhere to demarcate every kind of 
block: every control structure, every data structure and every function body.

This leads to a proliferation of nested braces which all have to be placed 
correctly in order for the code to be correct. Of course, we all use 
indentation to help manage this, but I think we all know that once the closing 
brace is sufficiently far from the opening brace, it becomes difficult to tell 
which brace matches which even with indentation. I think I spend a significant 
amount of my development time just eyeballing those closing braces. Of course, 
we also have editor features to help match them up but relying on such editor 
features might be an indication of a flaw in the language. At any rate, it 
impedes readability of the code, editor or no editor.

Not having the braces for each case is, to me, analogous to the way Swift 
removed the outermost parenthesis in the if statement conditional part. When 
you have a complex conditional expression with nested parentheses, removing 
that unnecessary outermost pair really improves readability (and reduces 
possibility of error). This can be done because the outermost parentheses 
aren’t really necessary to demarcate the boundaries of the expression.

Similarly, the case keywords in the switch statement sufficiently demarcate the 
extent of the statement block; it is unnecessary to toss in an extra pair of 
these brace characters that may already be heavily used in the statement block 
itself.

I think the extra burden on readability (and writability) of having the extra 
pair of nested braces is not justified by the desire for consistency. If 
consistency is so important, then rather than detracting from the quality of 
the switch statement by adding the braces, why don’t we improve the quality of 
the rest of the language by getting rid of some of those braces in the other 
constructs that use them! (Note: I don’t really expect that to happen…)

- Dennis D.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jasdev Singh via swift-evolution]

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-conformance.md

Would love any feedback or edge cases I may have missed!
-- 
@jasdev
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Leonardo Pessoa via swift-evolution]

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 Folders (both come from a common class called Entry). You as a developer 
for this system will be entitled to extend from File and Entry freely but you 
can only work with Folders and its subclasses (specialised folders) but to this 
system it is important you don't subclass any type of folder. Without this 
proposal I would have to create workarounds to prevent you from doing that 
while still allowing me to subclass while playing a lot of finals everywhere. 
And so far I would have to allow you to subclass Folder itself (at least) but 
you would complain (and possibly file a bug report to me) because it would not 
be working properly because your classes would not benefit from the workaround. 
In this case, if I could subclass internally but prevent you from doing it, you 
could complain I'm not allowing you to do whatever you want but you wouldn't 
complain my code doesn't work properly (it does, you just won't know it).

There may be several more examples but this is one I'm facing right now, so I 
can assure you it is a true example. IMO libraries are to be written with 
intention in mind and I don't think it is right to use a library written to 
compose a PDF file to send an email (even if you're sending the PDF file 
attached, the right way to do it is by composition not subclassing).

Additionally, someone mentioned and I went in to check about a recommendation 
for Java to intentionally document and enable classes to be subclasses 
explicitly otherwise forbid it at all and that recommendation seems to come 
from Oracle itself. I believe Oracle would do it to Java if it had great 
interest in it without consulting anyone's opinion.

About the addition to the proposal to enable force unsealing, I'm completely 
opposed as it is just like not having any of this protection at all (why 
putting a lock on the door to your house if the key is under the mat?)

Swift doesn't have to follow on the footsteps of any language but what is best 
for the intention the language was created for. If sealed by default goes in 
that direction, then we should have it not looking back. The same goes if we 
decide this is not taking the language in its intended direction. If I'm not 
wrong at least one member of the core team already mentioned in this thread 
this is completely aligned with the intention of the language, so I think we 
should give it a go and stop trying to have/keep control of everything we touch.

L

-Original Message-
From: "Tino Heth via swift-evolution" 
Sent: ‎10/‎07/‎2016 01:55 PM
To: "swift-evolution" 
Cc: "Jean-Daniel Dupas" 
Subject: Re: [swift-evolution] [Review] SE-0117: Default classes to 
benon-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 cancel the whole thing, because 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 about the actual pros 
and cons.

So for me, the promised benefits are less likely than the existence of Bigfoot:
I guess there are at least several hundred people who swore they have seen him, 
and there are even some blurry photos ;-)

Of course, it is impossible to come up with an unquestionable argument for the 
change — and it's also impossible to prove the opposite, because the whole 
debate makes as much sense as arguing wether raisins are tasteful or terrible; 
it's nothing but personal preference, and the only thing we can hope for is 
that the bias of those who will decide this proposal isn't at odds with the 
needs of the majority.

If we can agree that it is not about facts, but about opinion, there are still 
fundamental arguments against SE-0117:
Those who have issues with subclassing can just resign from it (as users of a 
library), and they can annotate their classes to dictate their usage (as an 
author) — but if you think subclassing is still a good tool, you can't do 
anything with a sealed class.
Additionally, please note that those who ask for stricter rules and more 
regulation have many reasons to be happy with the status quo:
You can subclass neither structs nor enums, and by default, you can't inherit 
from a framework-class as well, because it is internal — and yet they yell for 
more.

Swift claims to be opinionated, not to aim for compromise — but if plain old OO 
isn't compatible with the ideals of the language, it 

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

[L. Mihalkovic via swift-evolution]

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
>>> 
 On Jul 8, 2016, at 10:05 AM, Thorsten Seitz  wrote:
 
 
 
> Am 08.07.2016 um 15:59 schrieb Matthew Johnson :
> 
> 
> 
> Sent from my iPad
> 
>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  wrote:
>> 
>> 
>> 
>>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>>> :
>>> 
>>> 
>>> 
>>> 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 that 
> I know is equivalent to lack of care for good library design, but if 
> we want to push value types by making working with classes harder so 
> be it :P. 
 
 Making classes harder to work with is not a specific goal, no. :)
 
 I don't expect that this will be a significant burden for most Swift 
 programmers.  Mainly, that's because this only affects classes that 
 are exposed outside of a module, and the great majority of non-system 
 classes in a typical Cocoa program are single-purpose leaf classes 
 that — at most — expose a few methods to other subsystems.  Swift 
 doesn't really encourage you write complex classes that are primarily 
 customized with subclassing; it encourages the heavy use of value 
 types, and it encourages customization through protocols and 
 functions.  In fact, that's not really new to Swift, it's a general 
 lesson from the last few decades of software development: composing 
 smaller, independent systems through well-defined interfaces leads to 
 better software than building monolithic systems whose behavior can 
 only be defined in reference to the whole.
 
 I sympathize with the argument about wanting to fix bugs and add 
 features via override, but that's never been maintainable in the long 
 term; you always just end up with superclasses that everyone is 
 terrified to touch because every subclass has its own invasive 
 "fixes", and that's even when working within a single codebase.  With 
 libraries, you can pretty quickly get locked in to a specific version 
 because your customizations don't work with new releases; either that, 
 or the maintainer just decides that they can't fix of their mistakes 
 and so goes off to rewrite it from scratch.  Either way, it's not good 
 for the ecosystem.
 
 Plus, as others have mentioned, Swift already provides a lot of 
 features that don't allow overriding: structs, final, etc.  You simply 
 cannot rely on overriding to fix upstream bugs the way that you can in 
 most traditional OO languages because not enough code flows through 
 calls to overridable methods.  We should not compromise the goal of 
 promoting stronger and more maintainable library designs just to 
 maintain this illusion.
 
>>> 
>>> Thanks for continuing to make the case for this John.  I really, really 
>>> hope the core team will accept the proposal (with revisions - the 
>>> problems with the keyword names are real).  
>> 
>> 
>> What about
>> 
>>public internal(open) class Foo { ... }
>> 
>> similar to
>> 
>>public private(set) var foo: Foo
>> 
>> This would also allow e.g.
>> 
>>public fileprivate(open) class Foo { ... }
> 
> This is an interesting idea.
> 
> However it appears to have a problem in that it does not make 
> internal(open) the default for a public class or method if it behaves 
> consistently with private(set) (where the setter defaults to the same 
> visibility as the getter unless it is restricts further).  
 
 True, but the main feature of the proposal is being able to separate 
 control over visibility from control over the ability to subclass. This 
 would still be possible, just the default would be different.
>>> 
>>> Actually the main point of the proposal is to change the default.
>> 
>> I don’t understand? Just changing the default would mean introducing 
>> something like final by default (which was another proposal).
> 
> No, 

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

[Saagar Jha via swift-evolution]

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: ) but I agree that having to 
> implement
> a custom stream is kind of irritating for stderr and stdout.
> 
> import Cocoa
> 
> var str = "Hello, playground"
> 
> struct StderrStream: OutputStream {
> static var shared = StderrStream()
> func write(_ string: String) { fputs(string, stderr) }
> }
> 
> str.write(to: )
> 
> -- E
> 
> 
>> On Jul 8, 2016, at 4:41 PM, Saagar Jha via swift-evolution 
>> > wrote:
>> 
>> Currently, it’s rather annoying to print to standard error, requiring either 
>> something low-level like fputs. I was wondering if a standardError 
>> OutputStream could be added to the standard library, so we could write 
>> something like print(“foo”, ).
>> 
>> -- 
>> -Saagar Jha
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
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

[Peter Eddy via swift-evolution]

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 clearer, they're just visual noise.

If we insist on consistency then shouldn't we also do away with implicit
returns from single-expression closures? After all this behavior is
inconsistent with named functions. And shouldn't closures also declare
their signature before their opening brace, rather than after, also to be
consistent with named functions?

All these breaks with consistency have the effect of making the language
easier and more pleasant to read, and they don't seem to be major stumbling
blocks for people learning Swift. I hate to see them go away.

- Peter

On Fri, Jul 8, 2016 at 1:58 AM, G B via swift-evolution <
swift-evolution@swift.org> wrote:

> I’d imagine it would be the same just without the colon and with the
> braces:
>
>
> enum MyEnum {
> case IntEnum(Int)
> case StringEnum(String)
> }
>
>
> var x=MyEnum.StringEnum("Hello")
>
> switch x {
> case .IntEnum(let x) {
> print(x)
> }
>
> case .StringEnum(let x) {
> print(x)
> }
>
> }
>
>
>
> Not much different than:
>
> if case .StringEnum(let v) = x {
> print(v+" again")
> }
>
> except that the switch compares all case statements against x.
>
>
>
> > On Jul 7, 2016, at 10:37 PM, David Sweeris  wrote:
> >
> > What would be the proposed syntax for cases with associated values?
> >
> > In general, +1 for simplifying the syntax, but I'm not sure it'd work
> well, given that enums take on a larger roll in Swift than they do in other
> languages. Or maybe it'd be fine... I'm just too tired to picture it in my
> head.
> >
> > - Dave Sweeris
> >
> >> On Jul 7, 2016, at 15:07, G B via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> It has always seemed odd to me that `case`s use a colon as a delimiter
> rather than curly braces like everything else.  Is there a reason for this
> other than the legacy of C-like languages?
> >>
> >> If I wanted to write a series of branching `if` \ `else` statements I
> would do it like so:
> >>
> >> if x==0  { print(0) }
> >> else if x==1 { print (1) }
> >> else if x==2 { print(2) }
> >> else { print("other”) }
> >>
> >> I believe all flow control is wrapped in curly braces, except for
> `case`s inside a `switch`:
> >>
> >> switch x {
> >> case 0: print(0)
> >> case 1: print(1)
> >> case 2: print(2)
> >> default: print("other")
> >> }
> >>
> >>
> >> I feel like this would be more consistent with the rest of the syntax:
> >>
> >> switch x {
> >> case 0 { print(0) }
> >> case 1 { print(1) }
> >> case 2 { print(2) }
> >> default { print("other”) }
> >> }
> >>
> >> The colon syntax evokes a label, but the modern, complex `case`
> statements in Swift don’t act much like labels.
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Thorsten Seitz via swift-evolution]

> 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 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 iPad
> 
> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz  > wrote:
> 
>> 
>> 
>> Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
>> >:
>> 
>>> 
>>> 
>>> 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 that 
> I know is equivalent to lack of care for good library design, but if 
> we want to push value types by making working with classes harder so 
> be it :P. 
 
 Making classes harder to work with is not a specific goal, no. :)
 
 I don't expect that this will be a significant burden for most Swift 
 programmers.  Mainly, that's because this only affects classes that 
 are exposed outside of a module, and the great majority of non-system 
 classes in a typical Cocoa program are single-purpose leaf classes 
 that — at most — expose a few methods to other subsystems.  Swift 
 doesn't really encourage you write complex classes that are primarily 
 customized with subclassing; it encourages the heavy use of value 
 types, and it encourages customization through protocols and 
 functions.  In fact, that's not really new to Swift, it's a general 
 lesson from the last few decades of software development: composing 
 smaller, independent systems through well-defined interfaces leads to 
 better software than building monolithic systems whose behavior can 
 only be defined in reference to the whole.
 
 I sympathize with the argument about wanting to fix bugs and add 
 features via override, but that's never been maintainable in the long 
 term; you always just end up with superclasses that everyone is 
 terrified to touch because every subclass has its own invasive 
 "fixes", and that's even when working within a single codebase.  With 
 libraries, you can pretty quickly get locked in to a specific version 
 because your customizations don't work with new releases; either that, 
 or the maintainer just decides that they can't fix of their mistakes 
 and so goes off to rewrite it from scratch.  Either way, it's not good 
 for the ecosystem.
 
 Plus, as others have mentioned, Swift already provides a lot of 
 features that don't allow overriding: structs, final, etc.  You simply 
 cannot rely on overriding to fix upstream bugs the way that you can in 
 most traditional OO languages because not enough code flows through 
 calls to overridable methods.  We should not compromise the goal of 
 promoting stronger and more maintainable library designs just to 
 maintain this illusion.
 
>>> 
>>> Thanks for continuing to make the case for this John.  I really, really 
>>> hope the core team will accept the proposal (with revisions - the 
>>> problems with the keyword names are real).  
>> 
>> 
>> What about
>> 
>>public internal(open) class Foo { ... }
>> 
>> similar to
>> 
>>public private(set) var foo: Foo
>> 
>> This would also allow e.g.
>> 
>>public fileprivate(open) class Foo { ... }
> 
> This is an interesting idea.
> 
> However it appears to have a problem in that it does not make 
> internal(open) the default for a public class or method if it behaves 
> consistently with private(set) (where the setter defaults to the same 
> visibility as the getter unless it is restricts further).  
 
 True, but the main feature of the proposal is being able to separate 
 control over visibility from control over the ability to subclass. This 
 would still be possible, just the default would be different.
>>> 
>>> 

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

[Thorsten Seitz via swift-evolution]

> 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 iPad
>>> 
>>> On Jul 8, 2016, at 8:48 AM, Thorsten Seitz >> > wrote:
>>> 
 
 
 Am 08. Juli 2016 um 15:11 schrieb Matthew Johnson via swift-evolution 
 >:
 
> 
> 
> 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 that I 
>>> know is equivalent to lack of care for good library design, but if we 
>>> want to push value types by making working with classes harder so be it 
>>> :P. 
>> 
>> Making classes harder to work with is not a specific goal, no. :)
>> 
>> I don't expect that this will be a significant burden for most Swift 
>> programmers.  Mainly, that's because this only affects classes that are 
>> exposed outside of a module, and the great majority of non-system 
>> classes in a typical Cocoa program are single-purpose leaf classes that 
>> — at most — expose a few methods to other subsystems.  Swift doesn't 
>> really encourage you write complex classes that are primarily customized 
>> with subclassing; it encourages the heavy use of value types, and it 
>> encourages customization through protocols and functions.  In fact, 
>> that's not really new to Swift, it's a general lesson from the last few 
>> decades of software development: composing smaller, independent systems 
>> through well-defined interfaces leads to better software than building 
>> monolithic systems whose behavior can only be defined in reference to 
>> the whole.
>> 
>> I sympathize with the argument about wanting to fix bugs and add 
>> features via override, but that's never been maintainable in the long 
>> term; you always just end up with superclasses that everyone is 
>> terrified to touch because every subclass has its own invasive "fixes", 
>> and that's even when working within a single codebase.  With libraries, 
>> you can pretty quickly get locked in to a specific version because your 
>> customizations don't work with new releases; either that, or the 
>> maintainer just decides that they can't fix of their mistakes and so 
>> goes off to rewrite it from scratch.  Either way, it's not good for the 
>> ecosystem.
>> 
>> Plus, as others have mentioned, Swift already provides a lot of features 
>> that don't allow overriding: structs, final, etc.  You simply cannot 
>> rely on overriding to fix upstream bugs the way that you can in most 
>> traditional OO languages because not enough code flows through calls to 
>> overridable methods.  We should not compromise the goal of promoting 
>> stronger and more maintainable library designs just to maintain this 
>> illusion.
>> 
> 
> Thanks for continuing to make the case for this John.  I really, really 
> hope the core team will accept the proposal (with revisions - the 
> problems with the keyword names are real).  
 
 
 What about
 
public internal(open) class Foo { ... }
 
 similar to
 
public private(set) var foo: Foo
 
 This would also allow e.g.
 
public fileprivate(open) class Foo { ... }
>>> 
>>> This is an interesting idea.
>>> 
>>> However it appears to have a problem in that it does not make 
>>> internal(open) the default for a public class or method if it behaves 
>>> consistently with private(set) (where the setter defaults to the same 
>>> visibility as the getter unless it is restricts further).  
>> 
>> True, but the main feature of the proposal is being able to separate control 
>> over visibility from control over the ability to subclass. This would still 
>> be possible, just the default would be different.
> 
> Actually the main point of the proposal is to change the default.

I don’t understand? Just changing the default would mean introducing something 
like final by default (which was another proposal).


>  It would still be useful without a new default but would have a 
> significantly smaller impact.  The ecosystem advantages of the change in 
> default would not be realized.

Hmm, not sure about that.

-Thorsten


> 
> It seems to me like most supporters of the 

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

[Georgios Moschovitis via swift-evolution]

> > 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 *new* data-parallel code or graphics shaders using 
Swift. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

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 cancel the whole thing, because 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 about the actual pros 
and cons.

So for me, the promised benefits are less likely than the existence of Bigfoot:
I guess there are at least several hundred people who swore they have seen him, 
and there are even some blurry photos ;-)

Of course, it is impossible to come up with an unquestionable argument for the 
change — and it's also impossible to prove the opposite, because the whole 
debate makes as much sense as arguing wether raisins are tasteful or terrible; 
it's nothing but personal preference, and the only thing we can hope for is 
that the bias of those who will decide this proposal isn't at odds with the 
needs of the majority.

If we can agree that it is not about facts, but about opinion, there are still 
fundamental arguments against SE-0117:
Those who have issues with subclassing can just resign from it (as users of a 
library), and they can annotate their classes to dictate their usage (as an 
author) — but if you think subclassing is still a good tool, you can't do 
anything with a sealed class.
Additionally, please note that those who ask for stricter rules and more 
regulation have many reasons to be happy with the status quo:
You can subclass neither structs nor enums, and by default, you can't inherit 
from a framework-class as well, because it is internal — and yet they yell for 
more.

Swift claims to be opinionated, not to aim for compromise — but if plain old OO 
isn't compatible with the ideals of the language, it would be more honest to 
just completely remove inheritance instead of slowly crippling it's 
possibilities.

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

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

[Adrian Zubarev via swift-evolution]

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 -> SomeType.Type (removed .self)

SomeType.self is SomeType.Type == true

func foo(metatype: T.Type) -> T {
 
// lets pretend T conforms to an initializable protocol  
return metatype.init()  
}
With some tweaking and a little tradeoff for Type we’d get this model:

SomeType.staticMember == Type.metatype.staticMember
SomeType.init == Type.metatype.init

SomeType -> Type() (initialized instance; removed .self)

SomeType == Type() == true

SomeType is Type() == true

func foo(type: Type) -> T {
 
print(type.size)
print(type.debugDescription)
print(type.hashValue)
 
// lets pretend T conforms to an initializable protocol  
return type.metatype.init()  
}


-- 
Adrian Zubarev
Sent with Airmail

Am 10. Juli 2016 um 17:28:35, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

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 Int.Type
}
There is no way to express the same type check with Type except this:

func isInt(type: Type) -> Bool {
  
return type == Type()
  
// since this check is something where we store/pass a type (name)
// we could implicitly convert `Int` into an instance of `Type`
//
// The result would look like this:
  
return type == Int // which is logically equivalent to `metatype is 
Int.Type`
}


-- 
Adrian Zubarev
Sent with Airmail

Am 10. Juli 2016 um 16:24:50, L. Mihalkovic (laurent.mihalko...@gmail.com) 
schrieb:


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.newInstance(), xxx.setValue()). The mirror api shows a general direction, 
maybe there is a way to squeeze a tiny subset in 3.0 (just like was done with 
P that will remain a degenerate case of the upcoming more general syntax). 
Maybe just enough for people not to have to use ObjectIdentifier(:Any.Type).

Regards
(From mobile)

On Jul 10, 2016, at 2:22 PM, Adrian Zubarev via swift-evolution 
 wrote:

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 initializer for our type.

SomeType.staticMember equals metatypeInstance.staticMemeber
SomeType.init equals metatypeInstance.init
It is also possible to extract some more information from the metatypes with 
the help of Buildin wrapper functions like sizeof or strideof. And the last but 
not the least we can use metatypes in type checking scenarios.

Last weak I asked the community if there is a need for all metatypes conform to 
the Hashable protocol, which would be really handy. The overall response was 
positive, even if only a handful of people responded.

The whole idea of metatypes conforming to Hashable kept me thinking how this 
might be solved in the future. The main problem is that metatypes provide 
direct access to initializer and static members of the type and a conformance 
to Hashable seems to be impossible without some compiler magic or a hidden 
hashValue property. The main confusion here might be that metatypes can be 
stored (at least while runtime) inside variables and pretend to be instances of 
a T.Type type.

That said, I’d like to consider of sealing the direct access to a metatype into 
a real type for the sake of extensibility and clarity.

I’m aware that my bikeshedding introduced more boilerplate in terms of 
accessing the initializer and static members through a bottleneck property 
called sealed. Furthermore there is one more character to type if we’d go with 
Type instead of T.Type.

This is why this is a discussion before making any further decisions. :)

PS: As I showed in my last code example a wrapper type Type can also provide 
a few more information about the metatype.

Type.size
Type.stride
Type.alignment
Furthermore sealing T.Type into Type does solve the problem with the 
array/dictionary shorthand syntax.

Only when one would store/pass a type (name) we’d implicitly convert SomeType 
to Type.

Declarations do not follow this implicit conversion:

func foo(_: SomeType) is not equivalent to func foo(_: Type)

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

[David Sweeris via swift-evolution]

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 
> context-switch.
I don't understand. That's the point of C++ interop... You call the C++ APIs 
from your Swift code.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

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.newInstance(), xxx.setValue()). The mirror api shows a general direction, 
maybe there is a way to squeeze a tiny subset in 3.0 (just like was done with 
P that will remain a degenerate case of the upcoming more general syntax). 
Maybe just enough for people not to have to use ObjectIdentifier(:Any.Type).

Regards
(From mobile)

> On Jul 10, 2016, at 2:22 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> 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 initializer for our 
> type.
> 
> SomeType.staticMember equals metatypeInstance.staticMemeber
> SomeType.init equals metatypeInstance.init
> It is also possible to extract some more information from the metatypes with 
> the help of Buildin wrapper functions like sizeof or strideof. And the last 
> but not the least we can use metatypes in type checking scenarios.
> 
> Last weak I asked the community if there is a need for all metatypes conform 
> to the Hashable protocol, which would be really handy. The overall response 
> was positive, even if only a handful of people responded.
> 
> The whole idea of metatypes conforming to Hashable kept me thinking how this 
> might be solved in the future. The main problem is that metatypes provide 
> direct access to initializer and static members of the type and a conformance 
> to Hashable seems to be impossible without some compiler magic or a hidden 
> hashValue property. The main confusion here might be that metatypes can be 
> stored (at least while runtime) inside variables and pretend to be instances 
> of a T.Type type.
> 
> That said, I’d like to consider of sealing the direct access to a metatype 
> into a real type for the sake of extensibility and clarity.
> 
> I’m aware that my bikeshedding introduced more boilerplate in terms of 
> accessing the initializer and static members through a bottleneck property 
> called sealed. Furthermore there is one more character to type if we’d go 
> with Type instead of T.Type.
> 
> This is why this is a discussion before making any further decisions. :)
> 
> PS: As I showed in my last code example a wrapper type Type can also 
> provide a few more information about the metatype.
> 
> Type.size
> Type.stride
> Type.alignment
> Furthermore sealing T.Type into Type does solve the problem with the 
> array/dictionary shorthand syntax.
> 
> Only when one would store/pass a type (name) we’d implicitly convert SomeType 
> to Type.
> 
> Declarations do not follow this implicit conversion:
> 
> func foo(_: SomeType) is not equivalent to func foo(_: Type)
> Array() == [SomeType]() but is not equivalent to [Type]() 
> == Array()
> Here is again my bikeshedding:
> 
> public struct Type : Hashable, CustomStringConvertible, 
> CustomDebugStringConvertible {
>  
> // `metatype` is a better name than `sealed`
> // The tradeoff is this bottleneck property
> 
> public let metatype: T.Type
>   
> public let hashValue: Int
>   
> public static var size: Int { get }
> public static var stride: Int { get }
> public static var alignment: Int { get }
>   
> public var size: Int { get }
> public var stride: Int { get }
> public var alignment: Int { get }
>   
> public var description: String { get }
> public var debugDescription: String { get }
> }
> 
> public func ==(lhs: Type, rhs: Type) -> Bool
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 10. Juli 2016 um 00:18:02, Chris Lattner (clatt...@apple.com) schrieb:
> 
>> Hi Adrian,
>> 
>> What’s the motivation for this change?
>> 
>> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Andrew Trick via swift-evolution]

> 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 proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>>  
>> 
> 
> 

I'm revising this proposal based on last week's feedback. A few of the
additive APIs are removed and a number of UnsafePointer and
UnsafeRawPointer methods are renamed.

Here is a PR for the revision. Note that the examples in the proposal
text still need to be updated:
https://github.com/apple/swift-evolution/pull/420

I updated the short-form summary of the API:
https://github.com/atrick/swift-evolution/blob/3122ace9d2fb55072ebd7395c7353fcbf497318a/proposals/0107-unsaferawpointer.md#full-unsaferawpointer-api

The full UnsafeRawPointer API with doc comments is here:
https://github.com/atrick/swift/blob/22e3a2885e4236888ec447a7148acf633d8544f5/stdlib/public/core/UnsafeRawPointer.swift.gyb

The UnsafePointer and UnsafeRawPointer changes are on this branch:
https://github.com/atrick/swift/commits/rawptr

If you wish to comment line-by-line on the detailed docs or
implementation, you can do so here:
https://github.com/apple/swift/pull/3437

--- 
I should preemptively answer the question "why do UnsafeRawPointer
methods take an explicit type argument when it can be inferred?". Such
as:

  rawPtr.initializeMemory(as: Int.self, ...)

These methods don't simply operate on values of some type, they
actively bind memory to that type. At the point of use, that type
needs to be explicit to convey that fact. It's important for
readability, comprehension, and correctness. We cannot rely on type
inferrence on some expression which can change without the original
author's intervention resulting in subtle miscompiles.

---
The only concern I have about this version of the proposal is this method name: 

  func copyBytes(from: UnsafeRawPointer, count: Int)

because `count` usually refers to a number of values. I think it should be:

  func copy(bytes: Int, from: UnsafeRawPointer)

-Andy

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

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

[Ted F.A. van Gaalen via swift-evolution]

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 Swift as a continuous "software laboratory”   :o)
neither would be OK, (as with all extremities)...

thanks
Ted  


> On 10.07.2016, at 00:20, Chris Lattner  wrote:
> 
> 
>> On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen  
>> wrote:
>> 
>> imho and after releasing Swift 3.0: 
>>  ===
>> 
>> Existing language elements should never be removed,
>>   (even if they are frowned upon, which occasionally is caused
>>by aspects of subjective opinion, lack of experience and premature vague 
>> statistics, we’re human aren’t we?)
>> and even if much better newer solutions are available. 
>> 
>> New language elements should be supplements, standing on their own,
>> with the purpose of extending Swift, not as changes of existing code, 
>> thus leaving the older equivalents intact as not to break older source code. 
> 
> Ted,
> 
> I recommend that you familiarize yourself with the goals for Swift 3, which 
> are described here:
> https://github.com/apple/swift-evolution
> 
> An excerpt:
> 
> "The primary goal of this release is to solidify and mature the Swift 
> language and development experience. While source breaking changes to the 
> language have been the norm for Swift 1 through 3, we would like the Swift 
> 3.x (and Swift 4+) languages to be as source compatible with Swift 3.0 as 
> reasonably possible.”
> 
> -Chris

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

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

[Adrian Zubarev via swift-evolution]

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 initializer for our type.

SomeType.staticMember equals metatypeInstance.staticMemeber
SomeType.init equals metatypeInstance.init
It is also possible to extract some more information from the metatypes with 
the help of Buildin wrapper functions like sizeof or strideof. And the last but 
not the least we can use metatypes in type checking scenarios.

Last weak I asked the community if there is a need for all metatypes conform to 
the Hashable protocol, which would be really handy. The overall response was 
positive, even if only a handful of people responded.

The whole idea of metatypes conforming to Hashable kept me thinking how this 
might be solved in the future. The main problem is that metatypes provide 
direct access to initializer and static members of the type and a conformance 
to Hashable seems to be impossible without some compiler magic or a hidden 
hashValue property. The main confusion here might be that metatypes can be 
stored (at least while runtime) inside variables and pretend to be instances of 
a T.Type type.

That said, I’d like to consider of sealing the direct access to a metatype into 
a real type for the sake of extensibility and clarity.

I’m aware that my bikeshedding introduced more boilerplate in terms of 
accessing the initializer and static members through a bottleneck property 
called sealed. Furthermore there is one more character to type if we’d go with 
Type instead of T.Type.

This is why this is a discussion before making any further decisions. :)

PS: As I showed in my last code example a wrapper type Type can also provide 
a few more information about the metatype.

Type.size
Type.stride
Type.alignment
Furthermore sealing T.Type into Type does solve the problem with the 
array/dictionary shorthand syntax.

Only when one would store/pass a type (name) we’d implicitly convert SomeType 
to Type.

Declarations do not follow this implicit conversion:

func foo(_: SomeType) is not equivalent to func foo(_: Type)
Array() == [SomeType]() but is not equivalent to [Type]() 
== Array()
Here is again my bikeshedding:

public struct Type : Hashable, CustomStringConvertible, 
CustomDebugStringConvertible {
 
// `metatype` is a better name than `sealed`
// The tradeoff is this bottleneck property

public let metatype: T.Type
  
public let hashValue: Int
  
public static var size: Int { get }
public static var stride: Int { get }
public static var alignment: Int { get }
  
public var size: Int { get }
public var stride: Int { get }
public var alignment: Int { get }
  
public var description: String { get }
public var debugDescription: String { get }
}

public func ==(lhs: Type, rhs: Type) -> Bool


-- 
Adrian Zubarev
Sent with Airmail

Am 10. Juli 2016 um 00:18:02, Chris Lattner (clatt...@apple.com) schrieb:

Hi Adrian,

What’s the motivation for this change?

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

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

[Andre via swift-evolution]

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 times where its absolutely necessary.

If its at all feasible… maybe something like ...


public class MyWorkaroundClass : @forceOpen(YourSealedClass) {  //Obligatory 
Compiler Warning Occurs
public override func @forceOpen(brokenFunc()) {/*FIXME*/}
}
(The above is just a rough idea, please don't yell at me for the ugliness... )

Just like we have forced unwrapping of optionals (for only when we really need 
it), I believe that we should be able to force unseal when we truly need it;

Another +1 if the keyword is changed from subclassable/overridable to something 
less confusing… since people might be easily be misled and think that even 
within thier own module if they don't mark it subclassable it won’t be 
subclassable… perhaps "open" is the better keyword…

public open class MyOpenClass {  
public open func openFunc() {/*OVERRIDE ME!*/}
}
In this case, "open" can only apply to public classes/methods/accessors, 
anything else using "open" ("private open" etc) will be an obvious error.

Please note that I am not against this proposal in theory; only that I would 
humbly request that the two items above be at least considered and I will 
happily jump on board.

>  * Is the problem being addressed significant enough to warrant a change to 
> Swift?
I do think it is, because the potential upsides are many, such as better 
fencing between modules and users of those modules, potential performance gains 
and making it more explicit to a library writer what he/she is going to make 
public and also modifiable by consumers of the provided API.

Again though, I would be reticent to agree 100% if there werent a way to punch 
though that fence when we need to, not allowing such a thing makes the 
environment too rigid/unproductive and thats not the Swift I want to continue 
using. Swift is not C++ minus the C… is it?

>  * Does this proposal fit well with the feel and direction of Swift?
I think overall it does because swift encourages more ad-hoc composition than 
inheritance based, so making inheritability more explicit does seem to fit in 
with the direction of Swift… although the lack of ability to escape that 
limitation just like we have with forced unwrapped optionals makes me feel its 
at the same time not fully in line with the direction of swift… hence the +0 
instead of a full +1.

>  * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
Someone here brought up Kotlin, but I have only dabbled with it.. It seems 
similar to that from what I can read… but I have no experience with writing or 
consuming a library in Kotlin.

>  * How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

I have been wrestling with this in my mind since late last year when it first 
appeared on the swift-evolution list as a general discussion. 
I was originally very very strongly -1 on this (especially coming from an 
Objective-C background), but after reading the proposal and everyones replies 
both for and against, and thinking again deeply about my own code, have come 
around to believe that there are potential gains for this that are worthwhile, 
but only if some flexibility remains in the language to work around classes 
that are both closed-source and has a defect that is needed to workaround 
though subclassing.
——

Pros
Better Fencing Between Modules
Potential Performance Gains
Subclassing is Discouraged Unless its Explicitly Thought About

Cons
Unable to Override a Method/Accessor on a Class that Needs Fixing but is Closed 
Source 
You are at the total mercy of the framework author… (this one is pretty big to 
be honest)


"Unknowns" that make it hard to judge...

What effect this will really have on the community… 
What true objective performance benefits we can expect from inter-module 
optimization…
Will this really make libraries any better?


——

Other thoughts...
While it can be said that because most libraries are open source, the need to 
subclass is lower now than ever -we can just go in and fix something and send a 
pull request-  those of us trapped in large corporations that have (usually 
poorly supported) SDKs shoved down our throats by the suits need a certain 
level of flexibility to work arounds things… 

In debating to support this or not, I am reminded of comments by many here: 
http://mjtsai.com/blog/2015/12/21/swift-proposal-for-default-final/

——


Thanks,

Andre


> 2016/07/06 8:11、Chris Lattner via swift-evolution  
> のメール：
> 
> Hello Swift community,
> 
> The review of "SE-0117: Default classes to be non-subclassable publicly" 
> begins 

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

[L. Mihalkovic via swift-evolution]

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 of the side effects of a good swift/c++ interop would eliminate the core 
objections to rewritting swiftc in swift, which IMH would propel forward some 
of the gaps that exist in the language to be able to do that cleanly. As long 
as swift remains an app language, completing the generics system or dealing 
with the question of module/submodule/namespace can be lower priorities with 
more time to complete.


> The other discussion, which I think was the intended topic of this thread, is 
> whether the benefits of parallel computing can be brought closer to Swift, 
> which I believe they can.
> 
> In most applications, if we can get 80% of the benefit of new hardware with 
> minimal code rewrites, most developers would take that in a heartbeat and 
> focus the specialized talent and careful efforts necessary to craft, profile 
> and maintain truly optimized code on only the most critical kernels.  Maybe 
> that critical code will be written in C++, or some other language better 
> suited to the task.
> 
> Is there a good reason why Swift can’t be made as suitable— or more suitable— 
> than C++ for the 80% kinds of tasks?  It seems to me that Swift would be well 
> suited for it.
> 
> 
> 
> 
>> On Jul 10, 2016, at 01:41 , Goffredo Marocchi via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On 10 Jul 2016, at 08:50, Georgios Moschovitis 
>>  wrote:
>> 
 working on C++ compatibility/interaction is  still quite key because of 
 the mountains of legacy and new code still written everyday in it.
>>> 
>>> Totally agree, but C++ interoperability is orthogonal to my original 
>>> request. Would love to have both!
>>> 
 Also, I think that the right language for the right domain and being able 
 to glue them together is quite key in the modern computing world and using 
 a single language in every computing domain is a chimera that can bring 
 more pain than good.
>>> 
>>> I disagree. IMO, the ‘babel’ of programming languages is one of the most 
>>> annoying problems in our industry. Besides, I don’t see how C++ is any more 
>>> suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
>>> like CUDA). Swift is starting from a clean-slate, and could definitely 
>>> become a ‘right’ language for this domain.
>> 
>> Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. 
>> Hint: it is more likely for Swift to have working C++ integration first than 
>> to wait for those to happen.
>> 
>> We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are 
>> still relatively niche and before any of those gets anywhere near the strong 
>> worldwide cross platform following that JavaScript (with the explosion of 
>> Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to 
>> keep nurturing and strengthening this language and tools for a while longer.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

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 not making 
>> everything sealed/unsubclassable by default?
> 
> I'd wager a guess that the strong desire not to break source compatibility 
> with existing code explains why Java and C++ are stuck forever with 
> suboptimal defaults.

May I suggest that you might want to read about it if you have any interest in 
making accurate statements about it.

> Some members of this list have a bit of background in C++ language design 
> (understatement of the day!); perhaps they know more.
> 
>> Is it possible that having library authors use something like a sealed 
>> keyword or similar is good enough for the default case?
> 
> Swift is to be safe by default. I believe open subclassability is a power 
> tool that's unsafe without adequate training and thick protective gear; 
> therefore, it is useful to require posting yellow/black hazard signs when it 
> is in use. Safety first.
> 
> "Opting for safety sometimes means Swift will feel strict, but we believe 
> that clarity saves time in the long run."

It each their own... some people like the mental comfort of others building 
safeguard for them, others like to live baring the full weight of the 
consequences of their choices. Nothing wrong, just two different approaches to 
life.


> 
> Karoly
> @lorentey
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[G B via swift-evolution]

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 parallel computing can be brought closer to Swift, 
which I believe they can.

In most applications, if we can get 80% of the benefit of new hardware with 
minimal code rewrites, most developers would take that in a heartbeat and focus 
the specialized talent and careful efforts necessary to craft, profile and 
maintain truly optimized code on only the most critical kernels.  Maybe that 
critical code will be written in C++, or some other language better suited to 
the task.

Is there a good reason why Swift can’t be made as suitable— or more suitable— 
than C++ for the 80% kinds of tasks?  It seems to me that Swift would be well 
suited for it.




> On Jul 10, 2016, at 01:41 , Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On 10 Jul 2016, at 08:50, Georgios Moschovitis 
>  wrote:
> 
>>> working on C++ compatibility/interaction is  still quite key because of the 
>>> mountains of legacy and new code still written everyday in it.
>> 
>> Totally agree, but C++ interoperability is orthogonal to my original 
>> request. Would love to have both!
>> 
>>> Also, I think that the right language for the right domain and being able 
>>> to glue them together is quite key in the modern computing world and using 
>>> a single language in every computing domain is a chimera that can bring 
>>> more pain than good.
>> 
>> I disagree. IMO, the ‘babel’ of programming languages is one of the most 
>> annoying problems in our industry. Besides, I don’t see how C++ is any more 
>> suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
>> like CUDA). Swift is starting from a clean-slate, and could definitely 
>> become a ‘right’ language for this domain.
> 
> Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. 
> Hint: it is more likely for Swift to have working C++ integration first than 
> to wait for those to happen.
> 
> We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are 
> still relatively niche and before any of those gets anywhere near the strong 
> worldwide cross platform following that JavaScript (with the explosion of 
> Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep 
> nurturing and strengthening this language and tools for a while longer.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Thorsten Seitz via swift-evolution]

> Am 06.07.2016 um 13:39 schrieb Matthew Johnson via swift-evolution 
> :
> 
> 
> 
> 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 {} // Not publicly subclassable? Or is the subclassability 
>> inherited?
> 
> This is a great question.  There are really two questions: 
> 
> Can B be marked "subclassable" even though its superclass isn't?  Allowing 
> this allows creation of new classes with A as an ancestor.  Since this is 
> explicitly opt-in all within the same module I'm inclined to say we should 
> allow it.  
> 
> Is subclassability inherited by in-module subclasses?  This seems to me 
> opposed to the spirit of closed by default.  I think it is better to require 
> annotation on *every* class an method that is open to extension outside the 
> module, regardless of what choice a superclass makes,
> 
> This gives module authors the most control over *exactly* which classes can 
> be used as superclasses outside the module (A and C don't need to be 
> subclassable just because B needs to be.

I totally agree with both points.

-Thorsten 


> 
> -Matthew
> 
>> 
>> I'm not a big fan of the subclassable keyword either since it's quite long, 
>> not to mention it contains "class" which is the next keyword, making it 
>> visually repetitive.
>> 
>> I'd prefer open on both class and func to introduce only one keyword instead 
>> of two and possibly make it as a modifier of public to keep it in line with 
>> private(set)...
>> 
>>> On Jul 6, 2016, at 1:11 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0117: Default classes to be non-subclassable publicly" 
>>> begins now and runs through July 11. The proposal is available here:
>>> 
>>>   
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>>   https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and contribute to the direction of Swift. 
>>> When writing your review, here are some questions you might want to answer 
>>> in your review:
>>> 
>>>   * What is your evaluation of the proposal?
>>>   * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>>   * Does this proposal fit well with the feel and direction of Swift?
>>>   * If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>>   * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>>   https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

On 10 Jul 2016, at 08:50, Georgios Moschovitis  
wrote:

>> working on C++ compatibility/interaction is  still quite key because of the 
>> mountains of legacy and new code still written everyday in it.
> 
> Totally agree, but C++ interoperability is orthogonal to my original request. 
> Would love to have both!
> 
>> Also, I think that the right language for the right domain and being able to 
>> glue them together is quite key in the modern computing world and using a 
>> single language in every computing domain is a chimera that can bring more 
>> pain than good.
> 
> I disagree. IMO, the ‘babel’ of programming languages is one of the most 
> annoying problems in our industry. Besides, I don’t see how C++ is any more 
> suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
> like CUDA). Swift is starting from a clean-slate, and could definitely become 
> a ‘right’ language for this domain.

Also, call me when we get a port of either OpenCL or CUDA bindings in Swift. 
Hint: it is more likely for Swift to have working C++ integration first than to 
wait for those to happen.

We can talk about Swift, Rust, Kotlin, Eiffel, Scala, etc... but they are still 
relatively niche and before any of those gets anywhere near the strong 
worldwide cross platform following that JavaScript (with the explosion of 
Node.JS too), Ruby, C/C++, Java, and C#/.NET still have, we will need to keep 
nurturing and strengthening this language and tools for a while longer.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

On 10 Jul 2016, at 08:50, Georgios Moschovitis  
wrote:

>> working on C++ compatibility/interaction is  still quite key because of the 
>> mountains of legacy and new code still written everyday in it.
> 
> Totally agree, but C++ interoperability is orthogonal to my original request. 
> Would love to have both!
> 
>> Also, I think that the right language for the right domain and being able to 
>> glue them together is quite key in the modern computing world and using a 
>> single language in every computing domain is a chimera that can bring more 
>> pain than good.
> 
> I disagree. IMO, the ‘babel’ of programming languages is one of the most 
> annoying problems in our industry. Besides, I don’t see how C++ is any more 
> suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
> like CUDA). Swift is starting from a clean-slate, and could definitely become 
> a ‘right’ language for this domain.

DSL's sometimes emerge to esse programming challenges, but often arise out of 
need to dominate the complexity of a domain by catering exclusively to it 
instead of a jack of all trades - master of none approach. In some cases, the 
ability to easily approach problems in a deterministic low level way, as well 
as the wealth of existing code dealing with those problems, is how C and C++ 
are still very very relevant. The rest is increasingly dominated by JavaScript 
and Node where performance at a very low power is not critical.

C++ gives you rope to hang yourself with, but in capable hands it gives you all 
the knobs and levers you need to extract high performance with a very high 
degree of determinism. 
Garbage collection, automatic reference counting, pass by copy value types with 
or without copy on write semantics, etc... there are several areas where other 
languages keep you abstracted from the hardware in a way that does not make 
performance predictable.
Memory fragmentation, control of allocations of stack and heap memory 
(preferably away from hot game loops), no extra performance hit when passing 
memory reference around or iterate on collections (yes people can destroy 
performance in not very obvious ways too).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kristóf Liliom via swift-evolution]

> I disagree. IMO, the ‘babel’ of programming languages is one of the most 
> annoying problems in our industry. Besides, I don’t see how C++ is any more 
> suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
> like CUDA). Swift is starting from a clean-slate, and could definitely become 
> a ‘right’ language for this domain.

It is more suitable because it is not pure C++. Don't forget that the Metal 
Shading Language is "only" based on C++11 and modified to be able to express 
GPU compute attributes.
For more info: 
https://developer.apple.com/library/ios/documentation/Metal/Reference/MetalShadingLanguageGuide/cplusplus/cplusplus.html#//apple_ref/doc/uid/TP40014364-CH8-SW1
 


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

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

[Georgios Moschovitis via swift-evolution]

> working on C++ compatibility/interaction is  still quite key because of the 
> mountains of legacy and new code still written everyday in it.

Totally agree, but C++ interoperability is orthogonal to my original request. 
Would love to have both!

> Also, I think that the right language for the right domain and being able to 
> glue them together is quite key in the modern computing world and using a 
> single language in every computing domain is a chimera that can bring more 
> pain than good.

I disagree. IMO, the ‘babel’ of programming languages is one of the most 
annoying problems in our industry. Besides, I don’t see how C++ is any more 
suitable than Swift for GPU/heterogenous stuff (without peculiar extensions 
like CUDA). Swift is starting from a clean-slate, and could definitely become a 
‘right’ language for this domain.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

I disagree. While it sounds nice to have a unified syntax working on C++ 
compatibility/interaction is  still quite key because of the mountains of 
legacy and new code still written everyday in it. Also, I think that the right 
language for the right domain and being able to glue them together is quite key 
in the modern computing world and using a single language in every computing 
domain is a chimera that can bring more pain than good.

Still, if we work out how to import C++ code well, you are probably going to 
get something very close to that you are wishing anyways :).

Sent from my iPhone

On 10 Jul 2016, at 07:17, Georgios Moschovitis via swift-evolution 
 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 
> context-switch.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Jul 10, 2016, at 1:37 AM, 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 here, where 
>> all of the subclasses are within a single module, but they are all public. 
>> The class also has a required initializer for dynamic construction, so that 
>> they could write something like this:
>> internal struct ModelContext { /*…*/ }
>> public class ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>>   // …
>> }
>> public class SimpleModel: ModelBase {
>>   internal required init(context: ModelContext) { /*…*/ }
>> }
>> public class MoreComplicatedModel: ModelBase { /*…*/ }
>> // (within some other type)
>> public func instantiateModelObject(_ type: Model) -> Model 
>> {
>>   return type.init(context: self.context)
>> }
>> That is, a public entry point calls a required initializer with an internal 
>> argument type. This is the only way to instantiate Model objects, and the 
>> internal context type doesn’t leak out into the public API.
>> Of course, Swift doesn’t allow this. If someone outside of the module 
>> subclasses ModelBase, there’s no way for them to provide the 
>> dynamically-dispatched 'init(context:)’, because they don’t have access to 
>> the internal ModelContext. The author of the library has to make the 
>> required initializers public, and either set the ModelContext separately or 
>> make it public as well. Even though no one outside the module should be 
>> using these APIs.
> 
> Can you remind us why does Swift need required initializers to have the same 
> access as the containing class?

Because without required initializers you can't do something like:

let cl: MyClass.Type = ...
let instance = cl.init(value: 0)

where MyClass has a required init(value: Int).

The issue here is that in order to be able to do this, subclasses that 
implement another initializer must implement this one as well - so it must be 
visible outside of the module if it is public.

> 
> Having only package-internal constructors in the public base class is the 
> usual pattern for exporting a sealed class hierarchy in some other languages, 
> like Java.
> 
> -- 
> Károly
> @lorentey
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Georgios Moschovitis via swift-evolution]

> Perhaps not Metal per se, but the ability to compile code to a heterogenous 
> architecture.

+1

> It seems like Swift has been laying a lot of the ground work to move in that 
> direction.

I have the same *feeling* but I am wondering if there is any substance in this 
or it’s just wishful thinking.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Georgios Moschovitis via swift-evolution]

> 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 context-switch.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution