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

[Jean-Denis Muys via swift-evolution]

Before and above anything else, if I read the proposal correctly, we will not 
be able any more to use math operator signs as operators, beyond the paltry 
half dozen or so in the ASCII character set???

I strongly oppose such a restriction. Maths symbols (including ∪) are widely 
recognised in the scientific community and this change, IIUC, is very hostile 
to any scientific computing.

Jean-Denis



> On 19 Oct 2016, at 08:34, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Dear Swift-Evolution community,
> 
> A few of us have been preparing a proposal to refine the definitions of 
> identifiers & operators. This includes some changes to the permitted Unicode 
> characters.
> 
> The latest (perhaps final?) draft is available here:
> 
> 
> https://github.com/jtbandes/swift-evolution/blob/unicode-id-op/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
> We'd welcome your initial thoughts, and will probably submit a PR soon to the 
> swift-evolution repo for a formal review. Full text follows below.
> 
> —Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
> 
> 
> Refining Identifier and Operator Symbology
> 
> Proposal: SE- 
> 
> Authors: Jacob Bandes-Storch , Erica Sadun 
> , Xiaodi Wu , Jonathan 
> Shapiro
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal seeks to refine and rationalize Swift's identifier and operator 
> symbology. Specifically, this proposal:
> 
> adopts the Unicode recommendation for identifier characters, with some minor 
> exceptions;
> restricts the legal operator set to the current ASCII operator characters;
> changes where dots may appear in operators; and
> disallows Emoji from identifiers and operators.
>  
> Prior
>  discussion threads & proposals
> 
> Proposal: Normalize Unicode identifiers 
> 
> Unicode identifiers & operators 
> ,
>  with pre-proposal 
>  (a 
> precursor to this document)
> Lexical matters: identifiers and operators 
> 
> Proposal: Allow Single Dollar Sign as Valid Identifier 
> 
> Free the '$' Symbol! 
> 
> Request to add middle dot (U+00B7) as operator character? 
> 
>  
> Guiding
>  principles
> 
> Chris Lattner has written:
> 
> …our current operator space (particularly the unicode segments covered) is 
> not super well considered. It would be great for someone to take a more 
> systematic pass over them to rationalize things.
> We need a token to be unambiguously an operator or identifier - we can have 
> different rules for the leading and subsequent characters though.
> …any proposal that breaks:
> 
> let 🐶🐮 = "moof"
> will not be tolerated. :-) :-)
>  
> Motivation
> 
> By supporting custom Unicode operators and identifiers, Swift attempts to 
> accomodate programmers and programming styles from many languages and 
> cultures. It deserves a well-thought-out specification of which characters 
> are valid. However, Swift's current identifier and operator character sets do 
> not conform to any Unicode standards, nor have they been rationalized in the 
> language or compiler documentation.
> 
> Identifiers, which serve as names for various entities, are linguistic in 
> nature and must permit a variety of characters to properly serve 
> non–English-speaking coders. This issue has been considered by the 
> communities of many programming languages already, and the Unicode Consortium 
> has published recommendations on how to choose identifier character sets — 
> Swift should make an effort to conform to these recommendations.
> 
> Operators, on the other hand, should be rare and carefull

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

[Jean-Denis Muys via swift-evolution]

I don't agree with the line of reasoning that goes something like that:

"Event though you have , I want to forbid every one
from using additive feature X because I don't like it, given "

I also don't understand why this would impede qualified import syntax. What
is wrong with:

import func Framework.someMethod, func OtherFramework.someOtherMethod

So far for me this is +1.

Because additive, not in scope for phase 1 of Swift 4, though, as most of
the topics on this list recently.

On 18 October 2016 at 08:01, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > I'd almost always prefer to have another three lines of a
> protocolvisible, than three lines of imports.
>
> Maybe you just need an editor that can fold the imports (e.g. JetBrains)
> ___
> 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-0144: Allow Single Dollar Sign as a Valid Identifier

[Jean-Denis Muys via swift-evolution]

While I already tersely supported this proposal, following all the negative
reactions, I feel compelled to revisit my position. The main reason is that
it strikes me that most points of view so far, including mine, were really
culturally short sighted, and far too much US-centric.

I totally agree that '$' being use by one (or even several) piece of code
is not reason enough to change the language. But I also think that it being
used by only one piece of code is no reason to reject the change.

Most of us, including me, have been blinded by two things:

1- the use of the $ sign in other programming languages
2- the use of the $ sign in Swift as a prefix for implicitly declared
closure parameters

I think this second use is not Swifty at all. It clearly (to me) would fail
the litmus test "if it wasn't there, would you add it to the language?". Of
course, it has been blessed by time, and it has *become* Swifty, by usage
because it's a useful feature, despite the choice of its syntax being so
ugly (to my non-american eyes).

Similarly, I believe the use of the $ in other language should not be a
guide in the decision here, either positively, nor negatively. We may pay
some mild attention to the concern that we should perhaps avoid some
confusion. I haven't seen much of that.

Now for the elephant in the room: '$' is a currency symbol. As such it
should be handled like any other currency symbol. Thinking otherwise would
be very culturally offensive.

So can I use € as an variable name in Swift? According to Xcode 8.1B3, yes.
Can I use any currency symbol as an variable name in Swift? According to
Xcode 8.1B3, not quite, but almost all of them.

According to Mac OS "Emoji and Symbols" browser, there are 37 currency
symbols in Unicode:

let currencyAndSymbols = "$€¥¢£₽₨₩฿₺₮₱₭₴₦৲৳૱௹﷼₹₲₪₡₫៛₵₢₸₤₳₥₠₣₰₧₯₶"
I tried every one of them as a variable name. All were accepted, except 3:
¥, ¢, £:

// let ¥ = 1 // error: expected pattern

Note the poor error message.

Here are 33 successful attempts:

let $ = 1

let € = 1

let ₽ = 1

let ₨ = 1

let ₩ = 1

let ฿ = 1

let ₺ = 1

let ₮ = 1

let ₱ = 1

let ₭ = 1

let ₴ = 1

let ₦ = 1

let ৲ = 1

let ৳ = 1

let ૱ = 1

let ௹ = 1

let ₹ = 1

let ₲ = 1

let ₪ = 1

let ₡ = 1

let ₫ = 1

let ៛ = 1

let ₵ = 1

let ₢ = 1

let ₸ = 1

let ₤ = 1

let ₳ = 1

let ₥ = 1

let ₠ = 1

let ₣ = 1

let ₰ = 1

let ₧ = 1

let ₯ = 1

let ₶ = 1

print("₶ = \(₶)")

print(₶+₶+₶)

And finally, there is the very weird Rial Sign: ﷼
It is ok to use it as an variable name too (again, according to Xcode8.1B3).
But when trying to use it, Xcode switches to right-to-left mode, which
makes for strange (for my occidental eyes) behaviour and display. All the
following is OK in Xcode:

// unusual Xcode right-to-left behavior with Rial Sign

let ﷼ = 21


print("﷼= \(﷼)") // will print ﷼= 21

Of course, this is just a data point, and Xcode8.1B3 should not be the
arbiter here. But I believe whether Swift accepts currency symbols as
variable names should be consistent. Either it accepts all of them, or it
includes all of them.

I see no reason to exclude them. On the contrary, it was a design feature
of Swift to relieve use from the shackles of the ASCII character set.

In conclusion, I believe this proposal must be accepted, and actually
expanded to include ¥, ¢, £, and also to make it explicit that currency
symbols can be used in variable names as first and only character, as first
of many characters, and at any position.

This would make $0, $1, $2… legal variable names. I believe this is OK.

What would happen to implicitly declared closure parameters then? Nothing.
They would continue to be implicitly declared in the context of closures
that do not declare their parameters explicitly, similarly to `self` being
implicitly declared in the context of a class. A user willing to use $0
there would be facing a name collision, which is OK.

Note that such a change is purely additive: no legal source code today
would fail with this change.

I hope that at the very least, I opened a new perspective on this proposal,
and I hope we can find a way to be less culturally biased.

Jean-Denis

* What is your evaluation of the proposal?

+1. However, it should be expanded to include all Unicode currency symbols.

* Is the problem being addressed significant enough to warrant a
change to Swift?

Very much so, because it reveals a significant inconsistency in the way the
language handles characters for identifiers.

* Does this proposal fit well with the feel and direction of Swift?

Very much so, considering the language made a point to support unicode
characters in identifiers, and '$' should behave consistently with the
other Unicode currency symbols.

* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

In the specific case, this is irrelevant. We are in territory only treaded
by Swift

* How much effort did you put int

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

[Jean-Denis Muys via swift-evolution]

A clear win for me. +1


> On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution 
>  wrote:
> 
> Introduction
> 
> This proposal addresses significant unexpected performance gaps when using 
> dictionaries. It introduces type-specific collections for a Dictionary 
> instance's keys and values properties.
> 
> New DictionaryKeys and DictionaryValues collections provide efficient key 
> lookup and mutable access to dictionary values, enabling updates to be 
> performed in-place and allowing copy-on-write optimization of stored values.
> 
>  
> Motivation
> 
> This proposal address two problems:
> 
> The Dictionary type keys implementation is inefficient, because 
> LazyMapCollection doesn't know how to forward lookups to the underlying 
> dictionary storage.
> Dictionaries do not offer value-mutating APIs. The mutating key-based 
> subscript wraps values in an Optional. This prevents types with copy-on-write 
> optimizations from recognizing they are singly referenced.
> This proposal uses the following [String: [Int]] dictionary to demonstrate 
> these problems:
> 
> var dict = ["one": [1], "two": [2, 2], "three": [3, 3, 3]]
>  
> Inefficient
>  dict.keys Search
> 
> Swift coders normally test key membership using nil checks or underscored 
> optional bindings:
> 
> if dict["one"] != nil {
> // ...
> }
> if let _ = dict["one"] {
> // ...
> }
> These approaches provide the expected performance of a dictionary lookup but 
> they read neither well nor "Swifty". Checking keys reads much better but 
> introduces a serious performance penalty: this approach requires a linear 
> search through a dictionary's keys to find a match.
> 
> if dict.keys.contains("one") {
> // ...
> }
> A similar dynamic plays out when comparing dict.index(forKey:) and 
> dict.keys.index(of:).
> 
>  
> Inefficient
>  Value Mutation
> 
> Dictionary values can be modified through the keyed subscript by direct 
> reassignment or by using optional chaining. Both of these statements append 1 
> to the array stored by the key "one":
> 
> // Direct re-assignment
> dict["one"] = (dict["one"] ?? []) + [1]
> 
> // Optional chaining
> dict["one"]?.append(1)
> Both approaches present problems. The first is complex and hard to read. The 
> second ignores the case where "one" is not a key in the dictionary. It forces 
> its check into a higher branch and encourages forced unwrapping. Furthermore, 
> neither approach allows the array to grow in place. They introduce an 
> unnecessary copy of the array's contents even though dict is the sole holder 
> of its storage.
> 
> Adding mutation to a dictionary's index-based subscripting isn't possible. 
> Changing a key stored at a particular index would almost certainly modify its 
> hash value, rendering the index incorrect. This violates the requirements of 
> the MutableCollection protocol.
> 
>  
> Proposed
>  Solution
> 
> This proposal adds a custom collection for the keys and values dictionary 
> properties. This follows the example set by String, which presents multiple 
> views of its contents. A new DictionaryKeys collection introduces efficient 
> key lookup, while a new DictionaryValues collection provides a mutable 
> collection interface to dictionary values.
> 
> These changes introduce a simple and efficient way of checking whether a 
> dictionary includes a key:
> 
> // Performant
> if dict.keys.contains("one") {
> // ...
> }
> As a mutable collection, values enables modification without copies or clumsy 
> code:
> 
> if let i = dict.index(forKey: "one") {
> dict.values[i].append(1)  // no copy here
> } else {
> dict["one"] = [1]
> }
> Both the keys and values collections share the same index type as Dictionary. 
> This allows the above sample to be rewritten as:
> 
> // Using `dict.keys.index(of:)`
> if let i = dict.keys.index(of: "one") {
> dict.values[i].append(1)
> } else {
> dict["one"] = [1]
> }
>  
> Detailed
>  design
> 
> The standard library introduces two new collection types: DictionaryKeys and 
> DictionaryValues.
> A Dictionary's keys and values property types change from LazyMapCollection 
> to these new types. 
> The new collection types are not directly constructable. They are presented 
> only as views into a dictionary.
> struct Dictionary: ... {
> var keys: DictionaryKeys { get }
> var values: DictionaryValues { get set }
> 
> // Remaining declarations
> }
> 
> /// A collection view of a dictionary's keys.
> struct DictionaryKeys: Collection {
> typealias Index = DictionaryInde

Re: [swift-evolution] Mark protocol methods with their protocol

[Jean-Denis Muys via swift-evolution]

I watched this thread with a lot of attention, starting neutral. You must say 
that Karl won me over. His proposal would make Swift more expressive, and less 
error prone in cases of protocol conformance with name collisions. I am at this 
point +1

Jean-Denis

Sent from my iPhone

> On 22 Sep 2016, at 07:15, Karl via swift-evolution 
>  wrote:
> 
> I would like to make it a requirement if not inside a protocol extension 
> which declares a conformance, and actually build the protocol name in to the 
> member in an ABI-breaking way. We could make it additive by generating 
> forwarding thunks from the old symbols to the new ones, but it would be 
> better if we could just solve the overlapping-members problem before then.
> 
> That would mean you never get collisions between protocol members. There’s 
> loads of amazing stuff we can do with that ability, and ways we can extend it 
> to reduce a lot of boilerplate that occurs when you want to have multiple 
> representations of the same data (String is just an example).
> 
> I don’t really care about the syntax we need to make it liveable. We could 
> automatically insert the protocol names for unambiguous members at call-site, 
> or something else.
> 
> This thread was originally about making the *syntax* a requirement; I agree 
> with that, and I would actually take it one (or several) steps further, 
> solving other problems along the way.
> 
>> On 22 Sep 2016, at 06:46, Russ Bishop  wrote:
>> 
>> 
>>> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> 
 on Tue Sep 20 2016, Karl  wrote:
 
 I think the best way is to prefix the member name with the protocol, e.g:
 
 protocol MyProto {
  var aVariable : Int
  func aFunction()
 }
 class MyClass : MyProto {
  var MyProto.aVariable : Int
  func MyProto.aFunction() { … }
 }
>>> ...
 CC-ing Dave A, to understand better if this fits with the vision of 
 protocols
>>> 
>>> I generally agree with Doug.  The canonical way to indicate “this
>>> method/property/type implements a requirement of protocol P” should be
>>> to define the entity in an extension that also adds conformance to P.
>>> If that's inadequate indication in some way we should find a way to
>>> enhance it.  I wouldn't mind the notation above, but only as a fallback,
>>> not a reuquirement.
>>> 
>>> -- 
>>> -Dave
>>> ___
>> 
>> Indeed this is exactly how C# handles Interfaces (protocols). The default is 
>> the exact same way Swift works - by matching names. If there is a collision 
>> you specify Protocol.memberName. Its simple and in the years I was writing 
>> C# code it was flexible enough to cover most reasonable scenarios, without 
>> adding a bunch of boilerplate.
>> 
>> Russ
>> 
> 
> ___
> 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] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

Hello,

I would like to suggest an additive evolution to Swift that might be in scope 
of phase 1 of Swift 4 (because it might have an impact on the ABI).

The idea is to extend the pattern matching abilities of Swift to enable a 
recursive programming style that’s very common in languages such as Lisp, ML, 
or Prolog on a collection that is processed as a list. By analogy to ML, Swift 
could do that on tuples, or on arrays, or on any similar, perhaps new, data 
type. This would allow the following for example:

func listOfDifferenceOfListElements (list: List) -> Int {

switch list {
case 〘〙: {
return 〘〙
}
case 〘 let a 〙: {
return 〘 a 〙
}
case 〘 let a, let b ⫸ let tail 〙: {
return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
}
}
}


Where I deliberately used unusual Unicode characters to denote syntax that 
would need to be invented:

- 〘〙 to denote the list-like data structure. It would be old style parenthesis 
if we wanted that to be Swift’s tuple, or the usual bracket if it was arrays
- ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
all elements following whatever has been pattern-matched so far
- ⋙ to denote a list append operator.

If we wanted the list data-type to be tuples, this would require the ability to 
build longer tuples from existing ones, i.e. build (a, b, c) from a and (b, c), 
or from (a) and (b, c) (appending tuples). Array seems more suitable, however.

So this post is to assess the interest in such a feature. Also note that while 
I have tried to have an occasional look at this mailing list in the past, due 
to its overwhelming volume, I may very well have missed a similar discussion in 
the past. In that case, I would appreciate a pointer.

As someone who developed Lisp and Prolog software professionally in a rather 
distant past, with an ever renewed sense of wonder, I would very much love to 
be able to use that programming style again when it makes sense.

If there is interest, I would be willing to write up an evolution proposal.

Jean-Denis Muys

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

Re: [swift-evolution] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

The recursive call should obviously read

return 〘 a-b 〙 ⋙ listOfDifferenceOfListElements(tail)

Jean-Denis




> On 06 Sep 2016, at 16:48, Jean-Denis Muys  wrote:
> 
> Hello,
> 
> I would like to suggest an additive evolution to Swift that might be in scope 
> of phase 1 of Swift 4 (because it might have an impact on the ABI).
> 
> The idea is to extend the pattern matching abilities of Swift to enable a 
> recursive programming style that’s very common in languages such as Lisp, ML, 
> or Prolog on a collection that is processed as a list. By analogy to ML, 
> Swift could do that on tuples, or on arrays, or on any similar, perhaps new, 
> data type. This would allow the following for example:
> 
> func listOfDifferenceOfListElements (list: List) -> Int {
> 
> switch list {
> case 〘〙: {
> return 〘〙
> }
> case 〘 let a 〙: {
> return 〘 a 〙
> }
> case 〘 let a, let b ⫸ let tail 〙: {
> return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
> }
> }
> }
> 
> 
> Where I deliberately used unusual Unicode characters to denote syntax that 
> would need to be invented:
> 
> - 〘〙 to denote the list-like data structure. It would be old style 
> parenthesis if we wanted that to be Swift’s tuple, or the usual bracket if it 
> was arrays
> - ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
> all elements following whatever has been pattern-matched so far
> - ⋙ to denote a list append operator.
> 
> If we wanted the list data-type to be tuples, this would require the ability 
> to build longer tuples from existing ones, i.e. build (a, b, c) from a and 
> (b, c), or from (a) and (b, c) (appending tuples). Array seems more suitable, 
> however.
> 
> So this post is to assess the interest in such a feature. Also note that 
> while I have tried to have an occasional look at this mailing list in the 
> past, due to its overwhelming volume, I may very well have missed a similar 
> discussion in the past. In that case, I would appreciate a pointer.
> 
> As someone who developed Lisp and Prolog software professionally in a rather 
> distant past, with an ever renewed sense of wonder, I would very much love to 
> be able to use that programming style again when it makes sense.
> 
> If there is interest, I would be willing to write up an evolution proposal.
> 
> Jean-Denis Muys
> 

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

[swift-evolution] pattern matching on variable-sized data type

[Jean-Denis Muys via swift-evolution]

Hello,

I would like to suggest an additive evolution to Swift that might be in scope 
of phase 1 of Swift 4 (because it might have an impact on the ABI).

The idea is to extend the pattern matching abilities of Swift to enable a 
recursive programming style that’s very common in languages such as Lisp, ML, 
or Prolog on a collection that is processed as a list. By analogy to ML, Swift 
could do that on tuples, or on arrays, or on any similar, perhaps new, data 
type. This would allow the following for example:

func listOfDifferenceOfListElements (list: List) -> Int {

switch list {
case 〘〙: {
return 〘〙
}
case 〘 let a 〙: {
return 〘 a 〙
}
case 〘 let a, let b ⫸ let tail 〙: {
return 〘 a-b 〙 ⋙ sumDifferenceOfListElements(tail)
}
}
}


Where I deliberately used unusual Unicode characters to denote syntax that 
would need to be invented:

- 〘〙 to denote the list-like data structure. It would be old style parenthesis 
if we wanted that to be Swift’s tuple, or the usual bracket if it was arrays
- ⫸ to pattern-match the tail of the list, i.e. the list composed of any and 
all elements following whatever has been pattern-matched so far
- ⋙ to denote a list append operator.

If we wanted the list data-type to be tuples, this would require the ability to 
build longer tuples from existing ones, i.e. build (a, b, c) from a and (b, c), 
or from (a) and (b, c) (appending tuples). Array seems more suitable, however.

So this post is to assess the interest in such a feature. Also note that while 
I have tried to have an occasional look at this mailing list in the past, due 
to its overwhelming volume, I may very well have missed a similar discussion in 
the past. In that case, I would appreciate a pointer.

As someone who developed Lisp and Prolog software professionally in a rather 
distant past, with an ever renewed sense of wonder, I would very much love to 
be able to use that programming style again when it makes sense.

If there is interest, I would be willing to write up an evolution proposal.

Jean-Denis Muys

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

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

[Jean-Denis Muys via swift-evolution]

This is a detail of implementation and doesn't have to be. You might even 
imagine the compiler emitting two versions of the code, one assuming the class 
will not be subclassed, the other not assuming that, and a smart linker linking 
the right version depending on the case. 

So for me, in the long run, this argument is not an argument at all.

Even then, is it really appropriate to sacrifice expressivity on the altar of 
(marginally) better performance?

Jean-Denis

> On 15 Aug 2016, at 09:50, Jean-Daniel Dupas via swift-evolution 
>  wrote:
> 
> The non subclassable across module boundary is not just a compiler enforced 
> limitation. Once you compile a module with classes that are ‘final’ in the 
> module, the compiler may devirtualize all call sites in the module, or even 
> inlining some calls, making subclassing unpredictable and pointless.
> 
> 
> ___
> 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] Sealed classes by default

[Jean-Denis Muys via swift-evolution]

I for one would very much like this discussion to start again.

Yes it was discussed. Unfortunately, it was discussed in a summer time when in 
my country at least, many of us are off the grid for vacation. This is not a 
criticism of the process of course, just an indication that not everyone may 
have had the chance to voice their concerns.

As I expressed it already, even after reading all the arguments for the 
decision, I stand convinced that this decision is a tragic mistake. Note that I 
agree with many of the given rationales. I just think that the decision doesn't 
follow.

I will not rehash everything, but I will make a couple of points that may not 
have been expressed stridently enough:

- many many many people expressed contrary voices, and where shut up by the 
core team's expressing their opinion in favor of preventing subclassability by 
default. See a small sample at 
http://mjtsai.com/blog/2016/07/17/swift-classes-to-be-non-publicly-subclassable-by-default/

- One reason I (and others) gave is that I would not trust any programmer 
(least of which myself) to have the double sight ability to foresee every use 
of their classes/libraries. One disingenuous answer to that was "if you don't 
trust the programmer, why do you use their code to begin with?". Well, I don't 
trust my spouse's ability to forecast the time it takes to drive from place A 
to place B. Yet I will not break up over that. Time and time again, I have 
heard Apple executives praise us developers for the use of Apple's technology 
that they would never have foreseen. This decision goes totally contrary to 
those praises.

This decision is bad, not because it makes the default for classes to be 
unsubclassable, but because it puts the power of final decision into the wrong 
hands: the library author's. 

As a result, guidelines everywhere will eventually mandate for library authors 
to make everything "open", exactly as the guidelines for public C++ classes is 
often to make methods virtual. This will nullify much of the benefits of the 
decision.

The final programmer, the client programmer who uses the class should have the 
final say. The class author is entitled to express "beware, you will likely 
shoot yourself in the foot". But the final programmer should have the power to 
answer "thanks for saying. Now give me that gun."

My hope is that we can give back the final say to the final programmer through 
an additive Swift evolution proposal down the line, which would explicitly 
allow her to "force open" a closed class. I believe that such an addition would 
right the wrong while still keeping he benefits of the decision.

I don't think that such a proposal would affect the ABI, so it seems to me this 
is not yet the time to come up with such a proposal. I may be wrong on that 
though: I am quite unclear on what does or does not affect the ABI. 

To conclude let me give you an anecdote: I was writing this in-house iPhone app 
for a client, that used the common UITabViewController UI model. We had 5 tabs 
and 5 icons and all was good. Then the client asked for a new feature into a 
new 6th tab and wanted a 6th icon to be squeezed in the tab bar. The Apple's UI 
guidelines the, and the UITabViewController class precluded that (it may have 
changed since, I haven't developed for iOS in quite a while). However user 
testing showed that it was quite OK to put 6 icons there. I was able to 
subclass UITabViewController to accommodate for that, despite the fact the it 
was not only not designed for that, but also actively designed to prevent that.

Now there are many reasons why it could be claimed that what I did was wrong. 
And I would agree with those I suspect. However, that I could do it (pondering 
all factors) was actually the difference between "yes but" and "no way". As a 
result, my customer was another happy Apple user.

With Swift and that decision, this would not have happened, and we would all 
have been the poorer for it.

I hope I that this additive proposal I mentioned above can see the light of day 
in due time.

Best regards,

Jean-Denis


> On Aug 14, 2016, at 14:26, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> You are not familiar with us Italians and our love for (hopefully reasonable) 
> arguing I see ;). I  commit to and accept the decision taken, but it remains 
> a decision I disagree with and something that will probably birth a painful 
> fork once say Android and/or other big corporations moved to Swift and 
> decided for example that they wanted a new set of rules.
> 
> Sent from my iPhone
> 
>> On 14 Aug 2016, at 11:14, Jean-Daniel Dupas via swift-evolution 
>>  wrote:
>> 
>> 
>>> Le 14 août 2016 à 11:17, John Holdsworth via swift-evolution 
>>>  a écrit :
>>> 
>>> Hi folks,
>>> 
>>> I see from building the latest Swift-3.0 branch that I’m a little behind 
>>> the times and this proposal has been accepted :(
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-p

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

[Jean-Denis Muys via swift-evolution]

>
> * What is your evaluation of the proposal?
>

I am strongly opposed to that proposal. I am mostly a lurker on this list,
the volume of which I cannot cope with. However, I feel this proposal is
important enough that I decided to invest more time than usual.
So I have read carefully the arguments presented here.
And I am still opposed to the proposal.
I believe no programmer, least of which myself, can be trusted with the
decision to reliably decide ahead of time that this or that class cannot or
will not be subclassed.
So strong -1 for me.


> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>

I don't think the problem is a problem at all.


> * Does this proposal fit well with the feel and direction of Swift?
>

Not in my mind. Swift aims for safety, but not at the price of inflexibility


* If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

I would compare it for example to the decision for the C++ developer to
mark methods virtual or not, with the usual recommendation to mark
everything virtual, especially the destructor

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

I read it and ready carefully the debate on this list.


On Tue, Jul 12, 2016 at 5:36 PM, Jon Akhtar via swift-evolution <
swift-evolution@swift.org> wrote:

> I completely agree, the programmer should have as much power as we can
> give them, even if it means allowing them to shoot themselves in the foot,
> because at the end of the day Swift isn¹t an academic exercise, it is a
> real world programming language, so it should be optimized for solving
> real world problems not having some kind of technical, philosophical, and
> stylistic perfection when those come at the cost of the former.
>
> So -1
>
> -Jon
>
> On 7/11/16, 16:00, "swift-evolution-boun...@swift.org on behalf of
> Jonathan Hull via swift-evolution"  behalf of swift-evolution@swift.org> wrote:
>
> >
> >> On Jul 10, 2016, at 7:48 PM, Rod Brown 
> wrote:
> >>
> >>> 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.
> >
> >My point is that you are completely ignoring an entire class of risk that
> >has a real-world $$$ cost.  Every time I have to use a framework under
> >this proposal, I am now completely at the mercy of the author.  In the
> >case of open source frameworks I can at least make a fork, but for closed
> >source frameworks (often from large companies where us using their
> >framework has been negotiated by the bosses) you have now just added
> >weeks to my development cycle while I wait for
> >big-company-who-doesn¹t-really-care-that-much to update their stuff.
> >(sure I can work on other things during that time, but delaying a launch
> >isn¹t free)
> >
> >Are you offering to explain to my boss/client why I can¹t add the feature
> >in a reasonable timeframe like I can with Objective C frameworks?  That
> >it may not even be possible now in Swift even though the Android guy just
> >did it in a few hours?
> >
> >Do you know what I am going to tell my boss/client?  "Don¹t use Swift for
> >frameworks² and ³Try to avoid partnering with companies that have Swift
> >frameworks².  "It is too much of a risk".  "We are giving them too much
> >control over the future of our productŠ"  I mean, it even affects the
> >prices that companies can charge for crappy frameworks. If I am asking
> >for a bunch of features that I NEED them to add to provide a basic
> >feature, that affects negotiations/price (vs a world where I can add it
> >myself if needed).  Sealed-by-default gives them leverage.
> >
> >To use your bridge analogy, which is better in the case that you haven¹t
> >provided a bridge for me:
> >1) I build my own bridge knowing that I will need to maintain it
> >periodically (usually on a predictable schedule)
> >2) Have everyone wait fo

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

[Jean-Denis Muys via swift-evolution]

Ted,

I basically disagree 100% with everything you wrote. I will not got into much 
details, but for me, technology that doesn’t evolve is dead technology.

Moreover, your main argument about large code bases, is not a good one: we now 
have migration tools that work quite well. They could be made even better, with 
some investment, that most (I think) would rather see invested in the leading 
edge.

Aversion to change is everywhere. It’s deeply engrained in us human beings. 
That’s why consultant make a living selling change management. I have seen 
people complain a lot about Apple releasing new versions of iOS for example. I 
have seen developers complain that Apple releases new versions of Xcode too 
frequently. I was even not too long ago in a position to do a web development 
job for a customer who wanted to support Internet Explorer 6. I have very 
little sympathy for such plights.

If you don’t want to maintain your Swift 2 code, don’t. But don’t prevent the 
rest of us from doing it, despite the efforts required.

I applaud the way the Swift team is handling those breaking changes, piling 
them up as early as possible, postponing additive changes to post 3.0. This is 
the way to minimise the efforts as much as possible. I hope that even then, 
source-breaking changes will continue to happen when they make sense. I am 
looking forward to a language that will get constantly better at enabling me to 
evolve my code in the most productive way. If my source code breaks, that is a 
very small price to pay.

Jean-Denis

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