Re: [swift-evolution] Returning nothing

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 21, 2016, at 7:51 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>>> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via swift-evolution 
>>>  wrote:
>>> 
>>> This may be a silly question - given that one of Swift’s design principles 
>>> is to be a language for new programmers and for APIs to read like English 
>>> phrases, should we replace the typealias of Void for the return type () 
>>> with Nothing.
>> 
>> Nothing was one of the names considered for the bottom type that replaces 
>> @noreturn 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md).
>>  I think it would be confusing to rename Void to Nothing.
> 
> I think on that issue the favourite for replacing @noreturn is Never or 
> NoReturn, rather than Nothing (since @noreturn doesn't return nothing, it 
> doesn't return in the first place), so Nothing is actually okay in that 
> regard.


TS 2.0 adopted 'never'

> 
> I wouldn't mind the change of name, as void to me suggests something like a 
> yawning abyss, which implies a substantive gap, rather than an actual absence 
> of something, whereas Nothing is a bit clearer. That said I've never had any 
> real trouble with Void, but can see Nothing being a tad easier to teach.
> 
> It's also not necessarily a very disruptive change, as many people don't 
> write -> Void and just omit it, though personally I prefer to always write it 
> out explicitly.
> ___
> 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] [Revision] [Pitch] Rename `T.Type`

[L. Mihalkovic via swift-evolution]

As unfocussed as original
Regards
(From mobile)

> On Jul 22, 2016, at 12:40 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md
> 
> Rename T.Type
> 
> Proposal: SE–0126
> Authors: Adrian Zubarev, Anton Zhilin
> Status: Revision
> Review manager: Chris Lattner
> Revision: 2
> Previous Revisions: 1
> Introduction
> 
> This proposal renames the current metatype T.Type notation and the global 
> function from SE–0096 to match the changes.
> 
> Swift-evolution threads:
> 
> [Pitch] Rename T.Type
> [Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror
> [Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror
> [Discussion] Seal T.Type into Type
> Motivation
> 
> In Swift metatypes have the following notation: T.Type
> 
> As already showed in SE–0096 and SE–0090 the Swift community strongly is in 
> favor of (re)moving magical intstance or type properties.
> 
> SE–0096 moves instanceOfT.dynamicType to type(of: T) -> T.Type.
> 
> SE–0090 aims to remove .self completely.
> 
> We propose to rename T.Type to a generic-like notation Metatype. To be 
> able to achieve this notation we have to resolve a few issues first.
> 
> Known issues of metatypes:
> 
> Assume this function that checks if an Int type conforms to a specific 
> protocol. This check uses current model of metatypes combined in a generic 
> context:
> 
> func intConforms(to _: T.Type) -> Bool {
>return Int.self is T.Type
> }
> 
> intConforms(to: CustomStringConvertible.self) //=> false
> 
> Int.self is CustomStringConvertible.Type  //=> true
> [1] When T is a protocol P, T.Type is the metatype of the protocol type 
> itself, P.Protocol. Int.self is not P.self.
> 
> [2] There isn’t a way to generically expression P.Type yet.
> 
> [3] The syntax would have to be changed in the compiler to get something that 
> behaves like .Type today.
> 
> Written by Joe Groff: [1] [2] [3]
> A possible workaround might look like the example below, but does not allow 
> to decompose P.Type:
> 
> func intConforms(to _: T.Type) -> Bool {
>   return Int.self is T
> }
> 
> intConforms(to: CustomStringConvertible.Type.self) //=> true
> We can extend this issue and find the second problem by checking against the 
> metatype of Any:
> 
> func intConforms(to _: T.Type) -> Bool {
> return Int.self is T
> }
> 
> intConforms(to: Any.Type.self) //=> true
> 
> intConforms(to: Any.self)  //=> true
> 
> Int.self is Any.Type   //=> Always true
> When using Any the compiler does not require .Type at all and returns true 
> for both variations.
> 
> The third issue will show itself whenever we would try to check protocol 
> relationship with another protocol. Currently there is no way (that we know 
> of) to solve this problem:
> 
> protocol P {}
> protocol R : P {}
> 
> func rIsSubtype(of _: T.Type) -> Bool {
> return R.self is T
> }
> 
> rIsSubtype(of: P.Type.self) //=> false
> 
> R.self is Any.Type //=> Always true
> R.self is P.Type   //=> true
> R.self is R.Type   //=> true
> We also believe that this issue is the reason why the current global 
> functions sizeof, strideof and alignof make use of generic (_: T.Type) 
> declaration notation instead of (_: Any.Type).
> 
> Proposed solution
> 
> Rename any occurrence of T.Type and T.Protocol to Metatype.
> 
> Revise metatypes internally.
> 
> When T is a protocol, T.self should always return an instance of Metatype 
> (old T.Type) and never a T.Protocol. Furthermore, metatypes should reflect 
> the same type relationship behavior like the actual types themselves.
> 
> To match the correct meaning and usage of the noun ‘Metatype’ from this 
> proposal, we also propose to rename the global function from SE–0096:
> 
> before: public func type(of instance: T) -> T.Type
> after: public func metatype(of instance: T) -> Metatype
> Examples:
> 
> protocol P {}
> protocol R : P {}
> class A : P {}
> class B : A, R {}
> 
> func `is`(metatype: Metatype, also _: Metatype ) -> Bool {
> return metatype is Metatype
> }
> 
> `is`(metatype: R.self, also: Any.self) //=> true | Currently: false
> `is`(metatype: R.self, also: P.self)   //=> true | Currently: false
> `is`(metatype: R.self, also: R.self)   //=> true
> 
> `is`(metatype: B.self, also: Any.self) //=> true | Currently: false
> `is`(metatype: B.self, also: P.self)   //=> true | Currently: false
> `is`(metatype: B.self, also: R.self)   //=> true | Currently: false
> `is`(metatype: B.self, also: A.self)   //=> true
> `is`(metatype: B.self, also: B.self)   //=> true
> 
> func cast(metatype: Metatype, to _: Metatype) -> Metatype? {
> return metatype as? Metatype
> }
> 
> cast(metatype: R.self, to: Any.self) //=> an Optional | 
> Currently: nil
> cast(metatype: R.self, to: P.self)   //=> an Optional   | 
> Currently: nil
> cast(metatype: R.self, to: R.self)   //=> an 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 21, 2016, at 4:59 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hello Brent, thank you for your feedback on the review process of our 
> proposal.
> 
> I think this proposal is a huge mess. I don’t understand why the split 
> between Type and Metatype exists. I think Mirror seems half-baked; it ought 
> to be omitted entirely until we can actually design a reflection system.
> The reason why we took Mirror here, is because there can be metatypes that 
> pretend to reflect T where the actual metatype could reflect U with 
> relationship like U : T:
> 
> class Superclass {}
> class Subclass : Superclass {}
> 
> let hidden: Any = Subclass()
> let dynamicMetatype = hidden.dynamicType // Any.Type
> dynamicMetatype as? Any.Type  //=> NOT nil
> dynamicMetatype as? Superclass.Type   //=> NOT nil
> dynamicMetatype as? Subclass.Type //=> NOT nil
> That is the reason why a standalone non-generic type was needed to solve the 
> problem with the ‘current’ Swift.
> 
> And I can’t even tell if these are actual problems. It’s possible that the 
> design is just fine, but the proposal explains it poorly. At minimum, the 
> proposal should be rewritten and the type names reconsidered. I’m not a 
> person who gets confused by metatypes, but I simply cannot make heads or 
> tails of this proposal.

The most immediate issue is that this is a set of possible tactical moves 
without a strategy to justify why they are the right ones. There is no doubt 
that some are good, but without a clear plan of what reflection is intended to 
provide in swift, then it looks like a random exercise.

Joe's idea of slicing them apart is interesting and likely what will happen if 
he says so, but in my mind it will push further away the fundamental question 
of giving a scope to reflection in swift. As i said privately, there are a lot 
of good papers out there exploring the different facets. The answer belongs to 
the core team: if swift is mostly for all 7-to-77 with an ipad, then what's in 
swift today is already too much, if on the other hand the goal is to help with 
writing efficient dynamic language runtimes in swift, then this proposal will 
need lots of TLC.


> My general sense of this area is that the main problem is the dual meaning of 
> T.Type. T.Type wants to simultaneously be the type of the type instance and 
> the supertype of all subtype type instances. But this breaks down with 
> protocols, because protocol existentials don’t conform to themselves. So we 
> end up with T.Protocol, which gets confusingly renamed when it crosses 
> generic boundaries.
> 
> I think the answer here is to split these two roles:
> 
> Metatype is the type of the type instance. T.self is of type Metatype. 
> (Yes, we can call it T.metatype if we want.)
> If we don’t go into the direction of Type there is no need to rename the 
> current T.self magic to T.metatype, that was only considered for the Type 
> model. .self will be removed one day anyways (hopefully).
> 
> Subtype-supertype relationships don’t translate directly to metaclasses; 
> Metatype is not a subtype of Metatype.
> Why is that so, see the example above?!
> 
> T.Subtype (or T.SubtypeMetatype? T.Conforming? this needs bikeshedding) is 
> the supertype of all metatypes for T and its subtypes. T.Subtype is sort of 
> like a protocol, in that there are no concrete instances of it, so it makes 
> no sense to instantiate it. For classes, it only includes required (i.e. 
> inherited) initializers.
> Happily, I believe—though I may be wrong—that we can mostly resyntax to fix 
> this immediate problem. Adding new capabilities, like extending the metatypes 
> of specific types and adding universal members, can wait (or mostly wait) for 
> another day.
> 
> (But in general, I would like to see those added directly on Metatype, and I 
> would like extending Metatype with instance members to be equivalent to 
> extending T with static/class members. I’d also like to conform metatypes to 
> protocols, to somehow define Metatype in the standard library as a relatively 
> ordinary Swift type, and to have a pony.)
> This is an interesting suggestion you mentioned there. But I think that would 
> imply that every member you’d add on the generic Metatype would be 
> automatically not available on any Swift type:
> 
> // Bikeshedding example:
> 
> buildin Metatype : Hashable {
> var hashValue: Int { .. }
> }
> 
> struct New {
> // NOT available anymore - even if it's needed for a different purpose
> static hashValue: Int { .. }  
> }
> The issue can be solve if metatypes gain a bottleneck access to the type T, 
> like Type.metatype for example.
> 
> // Bikeshedding example:
> 
> buildin Metatype : Hashable {
> var hashValue: Int { .. }
> var somethingToAccessT: T_XYZ { .. }
> }
> 
> struct New {
> static hashValue: Int { .. } // available again
> }
> If we now compare this to our Type 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

[L. Mihalkovic via swift-evolution]

said as much privately (just not that colorfully though) to author, trying to 
hint at a number of problems that limited its usefulness.

Regards
LM
(From mobile)

On Jul 21, 2016, at 11:30 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 20, 2016, at 5:18 PM, Chris Lattner  wrote:
>> 
>>* What is your evaluation of the proposal?
> 
> I think this proposal is a huge mess. I don't understand why the split 
> between `Type` and `Metatype` exists. I think `Mirror` seems half-baked; it 
> ought to be omitted entirely until we can actually design a reflection system.
> 
> And *I can't even tell if these are actual problems*. It's possible that the 
> design is just fine, but the proposal explains it poorly. At minimum, the 
> proposal should be rewritten and the type names reconsidered. I'm not a 
> person who gets confused by metatypes, but I simply cannot make heads or 
> tails of this proposal.
> 
> My general sense of this area is that the main problem is the dual meaning of 
> T.Type. T.Type wants to simultaneously be the type of the type instance and 
> the supertype of all subtype type instances. But this breaks down with 
> protocols, because protocol existentials don't conform to themselves. So we 
> end up with `T.Protocol`, which gets confusingly renamed when it crosses 
> generic boundaries.
> 
> I think the answer here is to split these two roles:
> 
> 1. `Metatype` is the type of the type instance. `T.self` is of type 
> `Metatype`. (Yes, we can call it `T.metatype` if we want.) 
> Subtype-supertype relationships don't translate directly to metaclasses; 
> `Metatype` is not a subtype of `Metatype`.
> 
> 2. `T.Subtype` (or `T.SubtypeMetatype`? `T.Conforming`? this needs 
> bikeshedding) is the supertype of all metatypes for `T` and its subtypes. 
> `T.Subtype` is sort of like a protocol, in that there are no concrete 
> instances of it, so it makes no sense to instantiate it. For classes, it only 
> includes required (i.e. inherited) initializers.
> 
> Happily, I believe—though I may be wrong—that we can mostly resyntax to fix 
> this immediate problem. Adding new capabilities, like extending the metatypes 
> of specific types and adding universal members, can wait (or mostly wait) for 
> another day.
> 
> (But in general, I would like to see those added directly on `Metatype`, and 
> I would like extending `Metatype` with instance members to be equivalent 
> to extending `T` with static/class members. I'd also like to conform 
> metatypes to protocols, to somehow define `Metatype` in the standard library 
> as a relatively ordinary Swift type, and to have a pony.)
> 
>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes.
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> I have no idea, because I can't understand the proposal.
> 
>>* If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> Most metatype (well, metaclass) systems I've worked with have been in more 
> dynamic, runtime-oriented languages like Objective-C and Ruby. 
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I've been following the threads since the beginning. (And I still don't 
> understand the proposal.) I haven't been able to articulate my objections; 
> honestly, I still can't, but I've run out of time to wait and see if I can 
> figure things out.
> 
> -- 
> 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] [Proposal][Discussion] Qualified Imports

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 21, 2016, at 9:20 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> 
> 
> ~Robert Widmann
> 
> 2016/07/21 0:13、Pyry Jahkola via swift-evolution  
> のメッセージ:
> 
>> 
 On 21 Jul 2016, at 09:51, Robert Widmann via swift-evolution 
  wrote:
 
 On Jul 20, 2016, at 9:37 PM, Félix Cloutier via swift-evolution 
  wrote:
 
 The problem is that by specifying "import Foo using (Baz)", I get nothing 
 else from Foo. If I only want to exclude one conflicting name, I would 
 have:
 
> import Foo
> import Bar hiding (Baz)
 
 In case of a conflict, my "internal monologue" is more like "take Baz from 
 Foo" than "don't take Baz from Bar".
 
>>> 
>>> How else would you resolve an ambiguity than by selecting the appropriate 
>>> declaration and hiding the others?  Swift’s semantic analysis cannot read 
>>> your mind, and neither can your (or mine) proposal for renaming syntax - in 
>>> that you still have to import both modules either way.  You may as well be 
>>> explicit about which name you’re actually using and which ones you’re 
>>> actually hiding, eh?
>> 
>> Simple! You don't need to hide the others if we enforce a rule that 
>> explicitly mentioning one in the current file imports that name as a 
>> fileprivate identifier which shadows the ones not explicitly mentioned:
> 
> What you're describing is making a distinction between an open module and an 
> imported module and is both additive and out of scope for this particular 
> proposal.  We didn't want to touch module re-exports until that proposal came 
> up later.  This is a fantastic idea that we have plans to incorporate in 
> there nonetheless.  This distinction is far more powerful than our current 
> approach of just opening every module that gets imported into the top level 
> namespace.
> 

But it is a very limiting approach as has been seen in other languages and 
described here... designing a good system is as much about what it does today 
as what it will allow tomorrow and at what cost. Addressing the needs of today 
in a carpe diem fashion is an approach that works well when u are unsure if 
there will ever be a tomorrow, not for building the foundations of a legacy. To 
quote someone smarter "today's solutions are tomorrow's problems".

>> 
>> import A using (X)
>> import B // also exports X which gets shadowed by A.X
>> import C // also exports X which gets shadowed by A.X
>> 
>> assert(X.self == A.X.self)
>> assert(X.self != B.X.self)
>> assert(X.self != C.X.self)
>> 
>> import D using (X)
>> // error: invalid redeclaration of 'X'
>> // note: previously declared here: 'import A using (X)'
>> 
>> typealias X = Int
>> // error: invalid redeclaration of 'X'
>> // note: previously declared here: 'import A using (X)'
>> 
>> That would go nicely hand-in-hand with the idea that explicitly importing a 
>> module with a qualified name brings in the name of that module to the 
>> current file's scope:
>> 
>> import A  // ok, unqualified import keeps A as a second-class 
>> identifier
>> import B as B // ok, qualified import makes B a first-class identifier 
>> in file scope
>> 
>> typealias A = Int // ok, shadows the module name A
>> 
>> typealias B = Int
>> // error: invalid redeclaration of 'Bar'
>> // note: previously declared here: 'import Bar as Bar'
>> 
>> Couldn't we find a synthesis with both the explicit qualification of modules 
>> and the explicit selection of imported names? I would strongly support that.
>> 
>> — Pyry
>> 
>> ___
>> 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] [Proposal][Discussion] Qualified Imports

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 21, 2016, at 12:38 AM, Robert Widmann  wrote:
> 
> As cannot (and should not) hide substructures and can be added later if you 
> so desire.
> 
> 
>> On Jul 20, 2016, at 3:36 PM, L. Mihalkovic  
>> wrote:
>> 
>> Hiding is not necessary if you import into a pseudo container... It means 
>> the ide does not have to keep track of whats here whats not on a per source 
>> file basis
>> 
>> Import CoreGraphics as cg
>> cg.x
>> 
>> Collisions are always avoided and there is only adding imports. Simple.
>> 

and what's more:

  Import CoreGraphics as cg
  cg.x()

and 
  Import CoreGraphics
  x()

don't even require two separate internal implementations in the compiler... 
Done well, the exact same code can handle both scenarios. 


>> Regards
>> (From mobile)
>> 
>>> On Jul 20, 2016, at 11:04 PM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jul 20, 2016, at 1:59 PM, Xiaodi Wu  wrote:
 
 Why is hiding in-scope but renaming out-of-scope?
>>> 
>>> 
>>> Because hiding and renaming can be used in combination to subset out APIs, 
>>> not alter them.
>>> 
 Both are additive to Swift,
>>> 
>>> As part of this proposal, both are source-breaking.
>>> 
 and as has been argued by others, the former is a special case of the 
 latter.
>>> 
>>> A special case that cannot cause large-scale file-relative changes to APIs. 
>>>  Renaming is primarily used in other languages that treat free functions as 
>>> more canonical than we do, or allow operator definitions that can be used 
>>> as notation.  In those cases, you often have your own notation you’d like 
>>> to use.  In Swift, such changes should be rare enough that if you can’t 
>>> solve them with a disambiguating qualified import then you can just 
>>> redeclare the identifier some other way (typealias, top-level let, wrapper 
>>> class, whatever).
>>> 
 
 On Wed, Jul 20, 2016 at 15:55 Brandon Knope  wrote:
> I meant is there any reason for requiring parentheses 
> 
>> On Jul 20, 2016, at 4:53 PM, Robert Widmann  wrote:
>> 
>> Renaming is out of scope for this proposal, that’s why.
>> 
>>> On Jul 20, 2016, at 1:26 PM, Brandon Knope  wrote:
>>> 
>>> I prefer this 100x more
>>> 
>>> Is there any reason why this wouldn't work?
>>> 
>>> Brandon 
>>> 
 On Jul 20, 2016, at 4:13 PM, Xiaodi Wu  wrote:
 
 Yeah, I'd be happy to lose the parentheses as well.
 
 In the last thread, my take on simplifying the proposed syntax was:
 
 ```
 import Swift using String, Int
 
 // or, for hiding:
 import Swift using Int as _
 ```
 
 The key simplification here is that hiding doesn't need its own 
 contextual keyboard, especially if we support renaming (a huge plus in 
 my book), as renaming to anything unused (or explicitly to `_`) is 
 what hiding is all about.
> On Wed, Jul 20, 2016 at 15:01 Brandon Knope  wrote:
> 
> 
>> On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> As Joe and others mentioned in the previous thread, this syntax 
>> could be greatly simplified in ways that resemble analogous 
>> facilities in other languages. In particular I think it's alarmingly 
>> asymmetrical that, in your proposal, `import Swift using (String)` 
>> imports *only* String while `import Swift hiding (String)` imports 
>> *everything but* String. This becomes evident when chained together:
>> 
>> ```
>> import Swift using (String, Int)
>> // imports only String and Int
>> import Swift using (String, Int) hiding (String)
>> // imports only Int
>> import Swift hiding (String, Int)
>> // imports everything except String and Int
>> import Swift hiding (String, Int) using (String)
>> // imports *nothing*? nothing except String? everything except Int? 
>> confusing.
>> ```
>> 
>> By contrast, Joe's proposed syntax (with some riffs) produces 
>> something much more terse *and* much more clear:
>> 
>> ```
>> import Swift.*
>> import Swift.(Int as MyInt, *)
>> import Swift.(Int as _, *)
>> ```
> 
> I really don't find this much clearer than the proposed one. The 
> proposal reads much clearer. 
> 
> Joe's syntax has a lot going on in my opinion.
> 
> For the proposal, do we really need the parentheses? It makes the 
> syntax look heavier
> 
> Brandon 

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

[L. Mihalkovic via swift-evolution]

Hiding is not necessary if you import into a pseudo container... It means the 
ide does not have to keep track of whats here whats not on a per source file 
basis

Import CoreGraphics as cg
cg.x

Collisions are always avoided and there is only adding imports. Simple.

Regards
(From mobile)

> On Jul 20, 2016, at 11:04 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> 
>> On Jul 20, 2016, at 1:59 PM, Xiaodi Wu  wrote:
>> 
>> Why is hiding in-scope but renaming out-of-scope?
> 
> 
> Because hiding and renaming can be used in combination to subset out APIs, 
> not alter them.
> 
>> Both are additive to Swift,
> 
> As part of this proposal, both are source-breaking.
> 
>> and as has been argued by others, the former is a special case of the latter.
> 
> A special case that cannot cause large-scale file-relative changes to APIs.  
> Renaming is primarily used in other languages that treat free functions as 
> more canonical than we do, or allow operator definitions that can be used as 
> notation.  In those cases, you often have your own notation you’d like to 
> use.  In Swift, such changes should be rare enough that if you can’t solve 
> them with a disambiguating qualified import then you can just redeclare the 
> identifier some other way (typealias, top-level let, wrapper class, whatever).
> 
>> 
>> On Wed, Jul 20, 2016 at 15:55 Brandon Knope  wrote:
>>> I meant is there any reason for requiring parentheses 
>>> 
 On Jul 20, 2016, at 4:53 PM, Robert Widmann  wrote:
 
 Renaming is out of scope for this proposal, that’s why.
 
> On Jul 20, 2016, at 1:26 PM, Brandon Knope  wrote:
> 
> I prefer this 100x more
> 
> Is there any reason why this wouldn't work?
> 
> Brandon 
> 
>> On Jul 20, 2016, at 4:13 PM, Xiaodi Wu  wrote:
>> 
>> Yeah, I'd be happy to lose the parentheses as well.
>> 
>> In the last thread, my take on simplifying the proposed syntax was:
>> 
>> ```
>> import Swift using String, Int
>> 
>> // or, for hiding:
>> import Swift using Int as _
>> ```
>> 
>> The key simplification here is that hiding doesn't need its own 
>> contextual keyboard, especially if we support renaming (a huge plus in 
>> my book), as renaming to anything unused (or explicitly to `_`) is what 
>> hiding is all about.
>>> On Wed, Jul 20, 2016 at 15:01 Brandon Knope  wrote:
>>> 
>>> 
 On Jul 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution 
  wrote:
 
 As Joe and others mentioned in the previous thread, this syntax could 
 be greatly simplified in ways that resemble analogous facilities in 
 other languages. In particular I think it's alarmingly asymmetrical 
 that, in your proposal, `import Swift using (String)` imports *only* 
 String while `import Swift hiding (String)` imports *everything but* 
 String. This becomes evident when chained together:
 
 ```
 import Swift using (String, Int)
 // imports only String and Int
 import Swift using (String, Int) hiding (String)
 // imports only Int
 import Swift hiding (String, Int)
 // imports everything except String and Int
 import Swift hiding (String, Int) using (String)
 // imports *nothing*? nothing except String? everything except Int? 
 confusing.
 ```
 
 By contrast, Joe's proposed syntax (with some riffs) produces 
 something much more terse *and* much more clear:
 
 ```
 import Swift.*
 import Swift.(Int as MyInt, *)
 import Swift.(Int as _, *)
 ```
>>> 
>>> I really don't find this much clearer than the proposed one. The 
>>> proposal reads much clearer. 
>>> 
>>> Joe's syntax has a lot going on in my opinion.
>>> 
>>> For the proposal, do we really need the parentheses? It makes the 
>>> syntax look heavier
>>> 
>>> Brandon 
>>> 
>>> 
>>> 
 
 
> On Wed, Jul 20, 2016 at 1:52 PM, Robert Widmann via swift-evolution 
>  wrote:
> Hello all,
> 
> I’d like to thank the members of the community that have guided the 
> revisions of this proposal.  We have decided to heed the advice of 
> the community and break down our original proposal on modules and 
> qualified imports into source-breaking (qualified imports) and 
> additive (modules) proposals.  As qualified imports is the change 
> most suited to Swift 3, we are pushing that proposal now as our final 
> draft.
> 
> It can be had inline with this email, on Github, or as a gist.
> 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jul 20, 2016, at 7:34 PM, John McCall via swift-evolution 
 wrote:

>>> On Jul 20, 2016, at 10:13 AM, Károly Lőrentey  wrote:
>>> On 2016-07-18, at 19:05, John McCall via swift-evolution 
>>>  wrote:
>>> The basic effect of Károly's counter-proposal is that every public member 
>>> of an open class has to be marked either "open" or "final".  That's 
>>> boilerplate.
>> 
>> My primary point was that there is no need for a middle ground between 
>> "final" and "open" members.
>> 
>> I want to push my primary point a little more, so let’s forget my secondary 
>> suggestion to have no default, and let’s set an implicit choice. 
>> 
>> I'd still argue for having no middle ground. “final” seems to be a good 
>> default; its effect matches the proposal.
>> 
>>> I think you and Károly are evaluating the addition of non-open methods as 
>>> if they were being added primarily to increase expressive capabilities.  
>>> They do marginally increase expressiveness, but I agree that it's not a 
>>> common situation to explicitly want.  However, neither are non-open 
>>> classes.  
>> 
>> It's more of an Occam's razor thing. The proposal prevents people from 
>> unintentionally exposing a wider API area than they intended. I agree with 
>> this wholeheartedly. I just don't believe that we need to add a brand new 
>> access level for members to achieve this goal.
>> 
>> Having an implicit "sealed" class level is a much easier sell for me, 
>> because it is sometimes desirable to expose a sealed class hierarchy, but 
>> Swift doesn't currently support it well -- AFAICT not as an intentional 
>> choice, but rather as an unfortunate side-effect of the initializer rules. 
>> You could've simply chosen to propose making "final" the default for public 
>> classes. Kotlin's troubles mostly wouldn't apply as long as internal classes 
>> would remain open, so I'd have supported that too. But rather than this, the 
>> proposal is built on top a nice solution to the sealed class problem. 
>> Solving it is obviously a good idea, and it is closely related to the goal 
>> of the proposal.
>> 
>> There is no such language problem in Swift 2 with sealed methods: an 
>> internal open member is sealed by virtue of not being externally visible. 
>> It’s straightforward to add a public final trampoline in the rare case when 
>> a sealed member should also be made externally callable. I believe the 
>> proposal works perfectly well without adding a language feature for this 
>> uncommon usecase.
>> 
>>> The goal here is not to create new expressive power, it's to establish a 
>>> comprehensible intermediate position that's acceptable as a default so that 
>>> publicizing an API doesn't require so much annotation and bookkeeping.  
>>> Otherwise, programmers are forced to immediately decide between 
>>> over-promising (by making the method publicly overridable) or breaking 
>>> their own code (if they have internal overrides).
>> 
>> But making API public should never be done in a hurry. It includes making 
>> the API presentable, which involves some amount of refactoring. Granted, if 
>> an API has internally overridden methods that the author wants to make 
>> public but sealed, then they'd need to refactor these methods. But given how 
>> rare this is, and how easy it is to implement the trampoline pattern, is 
>> such a trivial refactoring step really too much to ask? (There are a number 
>> of much more complicated refactorings involved in making an API public; 
>> e.g., it is often the case that a method I want to make public has a 
>> parameter or return value with a type that I wish to keep internal.)
> 
> I agree that having the concept of "visible publicly but only arbitrary 
> modifiable internally" adds complexity to the language.  However, once we've 
> got non-open public classes — and as I understand it, you still support those 
> — that complexity already exists.  You're not really eliminating anything by 
> preventing this from being applied to methods.
> 
> Also, we're going to be proposing a lot of new things for library-resilience 
> over the next six months or so that will add appreciable but unavoidable 
> complexity to the language around module boundaries.  Module boundaries have 
> a lot of special significance in the language design because Swift takes the 
> stable binary interface problem much more seriously than, I think, almost any 
> other language can claim to.

Considering how most people in this list likely do not understand where there 
is an issue and the fact that most of the planet's servers have done reasonably 
until today with only a pre9-java solution, i wonder who these enhancements are 
meant for? Binary sharing in the apple world is very limited outside apple, so 
at this point I question if these will be for users or something else we will 
have to overcome. 

>> I believe that apart from this one 

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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>>* What is your evaluation of the proposal?
> 
> I think the colon has too little visual weight for this role. In a property 
> declaration, the colon sits to the right of an identifier:
> 
>var widgetID: WidgetUUID
> 
> But in a subscript, it sits to the right of a long, punctuation-filled, and 
> potentially convoluted parameter list:
> 
>subscript(id widgetID: WidgetUUID): Widget { … }
> 
> In this environment, the colon vanishes.

You trumpet it like it is a universal truth... I have been back into lots of ts 
for 2 weeks now and low and behold none of the colons have vanished yet ;-) 
More seriously, I think u underestimate the way the brain just adapts. None of 
this is hard to read:

interface Hashable { getHash(): number }
Interface Dictionary { [name:string]:string|number }
interface T extends Hashable { }
class SomeTypeName {
  public getHash():number {
return ...;
  }
  public type():this {
return Type;
  }
}
function compare(lhs:SomeTypeName, 
rhs:SomeTypeName):boolean {
  return lhs.getHash() != rhs.getHash();
}

and neither is this:

export function newDataStore, U> (ctor: { new 
(config:DataStoreConfig):T}, config:DataStoreConfig):T {
   return new ctor(config)
}


> Using arrow instead gives us a symbol that not only stands out more, but 
> which is conventionally given spacing on both sides. Both of these assist you 
> in seeing the symbol, helping you visually parse the declaration. It also 
> helps that this symbol is not the same one used at least once and sometimes 
> more often within the parameter list itself.
> 
> Thus, we have the current syntax:
> 
>subscript(id widgetID: WidgetUUID) -> Widget { … }
> 
> I understand where the impulse comes from, I really do. Looked at as an 
> abstract question, colon is more correct, because there's no function 
> involved here. But subscript syntax faces many of the same challenges that 
> led to the adoption of the arrow in functions, and I think we have to go 
> where those human factors lead us.
> 
>>* Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes, I think proposals on this topic are appropriate.
> 
>>* Does this proposal fit well with the feel and direction of Swift?
> 
> No; I think that's where this proposal falls down. Swift happily emphasizes 
> clarity over purity, and I think arrow is clearer.
> 
>>* If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> Off the top of my head, I can't think of one with an analogous issue.
> 
>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Glance.
> 
> -- 
> 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] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 20, 2016, at 9:54 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> Hi Peter,
> 
>> Am 20.07.2016 um 00:26 schrieb Peter Livesey via swift-evolution 
>> :
>> 
>> 1. I don't understand what problem this solves?
> 
> That's just natural — most likely you have just a different mindset.
> 
> There are already several cases where "bureaucrats try to constrict freedom" 
> (sorry, it's hard to come up with neutral words here... but on the other 
> hand: a bureaucrat may have a much more positive interpretation of this term 
> than I ;-), and when I noticed it for the first time, I was really baffled 
> why someone tries hard to push a change that creates limitations without 
> offering any significant benefit…
> I found the missing piece to understand the situation here
> http://martinfowler.com/bliki/DirectingAttitude.html
> Fowler did a great job, and with this hint I realized why I couldn't find any 
> good arguments for the other side: There is none — at least for me, as It is 
> all only a matter of perspective.
> The only thing missing in Fowlers three articles are good designations for 
> members of the two camps (I personally refer to my side as the "hackers", and 
> I already mentioned the "bureaucrats" ;-)
> Imho the discussion would greatly improve if everybody accepted this model of 
> two contrary attitudes.
> 
> This insight really helped me to keep my sanity in the face of many others 
> acting absolutely "nuts", fighting for a change with nothing but downsides 
> and not even a single example that there are situations where it would be 
> beneficial for me.
> 
> So my advice: Be glad that you don't see such problems in your real work 
> life, and hope that the extremists who would like to completely remove 
> classic object orientation and cripple Swift to fully match their ideals 
> don't prevail ;-)

That ship has sailed... it is now just a matter of the implementation 
details... My hopes are now on google forking swift like they did to webkit and 
dalvik. It won't save the apps, bug it would the servers.

> 
> - Tino
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 9:17 PM, John McCall via swift-evolution 
>  wrote:
> 
>> On Jul 16, 2016, at 11:48 AM, Xiaodi Wu  wrote:
>> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution 
>>  wrote:
 On Jul 16, 2016, at 11:03 AM, T.J. Usiyan  wrote:
 "open is invalid on declarations that are not also public (see the 
 Alternatives discussion for rationale)."
 
 +
 
 "If an open class inherits an open method from a superclass, that method 
 remains open. If it overrides an open method from a superclass, the 
 override is implicitly open if it is not final."
 
 I understand that the intent is probably not to say that subclasses are 
 public by default. My point is that those two statements, without an 
 explicit spelling out of the implicit access level, could lead me to 
 believe that subclasses are implicitly public by default. It is open to 
 interpretation. Neither the prose nor the code examples address it.
>>> 
>>> I see your general point.  I'll think about how to re-word this; it may be 
>>> sufficient to just remove the requirement that open methods appear in open 
>>> classes.  Suffice it for me to say now, officially, that this proposal does 
>>> not require classes to be public or open just because they override open 
>>> methods from an open superclass.
>> 
>> It might be barely sufficient solely to remove the requirement that open 
>> methods appear in open classes. However, if my subclass is internal, I 
>> shouldn't be required to declare a `public override` of an open method just 
>> to satisfy the rules for `open`, which would be forced by the rule that 
>> `open` is invalid on declarations that are not also `public`
> 
> This rule only applies to explicit uses of "open".  A method that is 
> implicitly open due to overriding does not have this restriction.
> 
> In general, my intent in writing this proposal was to cover the important 
> interactions, not to write a fully precise specification.  The general rule 
> about overrides having to be at least as accessible as the minimum of their 
> class and their overridden method still applies, superseded only by the rule 
> that it is acceptable to drop the "open" on a public open override.
> 
>> combined with the rule that overrides of an open method are by default open.
> 
>> This would degrade the developer experience significantly, since a beginning 
>> developer writing only internal subclasses for their own app would now be 
>> required to litter either `public override` or `final override` throughout 
>> their code in the ordinary course of subclassing. On reconsideration, it 
>> might be best if overrides are not implicitly open.
> 
> I continue to think "override" is sufficient communication here.  We're not 
> going to have a model where the inherited open API of the superclass becomes 
> non-open in the subclass.

the logic of the proposal would dictate that it did: by subclasing the original 
type into a new type, the programmer is effectively removing any of the 
original guaranties that the first programmer made about how cohesively all 
paths into the type operated. The new code defines a new outer boundary for the 
subtype that has every reason not to be trusted by default to be working for 
subclasing, for the same reasons the original types could not be implicitely 
trusted either.

>  We don't want the mere existence of an override in the subclass to change 
> that because it's a fairly core goal that the existence of an override (at 
> least one which doesn't covariantly refine the type) in a subclass should not 
> affect source/binary compatibility.
> 
> John.
> 
> 
>> 
>>> 
>>> John.
>>> 
 
 
 On Sat, Jul 16, 2016 at 1:35 PM, John McCall  wrote:
>> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> Sent from my iPhone
>> 
>> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>>> Yes, sorry, my point was that this consideration isn't spelled out. 
>>> 
>>> Another question is whether or not making a subclass of an open class 
>>> public by default is what we want. I see why it would be, I just think 
>>> that it is a wrinkle to default to internal otherwise but not here.
>> 
>> I can't think of any good reason to assume a specific class should be 
>> public just because it is a subclass of an open class.  The internal 
>> default would still be the right default in this case.
> 
> Right, there's no new restriction here.  Of course you can make a private 
> or internal subclass of a public open class — otherwise, you'd have to 
> publicize every subclass of (say) UIViewController.
> 
> John.
> 
>> 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On 19 Jul 2016, at 19:37, L. Mihalkovic  wrote:
>> 
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
 
 Cocoa currently hides the boilerplate for all of these wonderful 
 constructs behind amazingly effective runtime acrobatics. This fits 
 perfectly into Objective-C, and it also works very well in Swift. But such 
 features could be in better harmony with Swift's unique set of language 
 constructs if their boilerplate was hidden behind amazingly effective 
 **compile-time** acrobatics instead.
 
 Such compile-time acrobatics are hard to perform today, and it is possible 
 that the ability to create such systems will forever remain an advanced 
 skill, just like forging runtime magic requires advanced skills in 
 Objective-C.
>>> 
>>> ... rantish...
>>> 
>>> I am still not convinced that even the best compiler can fully replace what 
>>> a powerful runtime can provide no matter the acrobatics you put in in terms 
>>> of compiler introduced utility code/constructs or the code analysis efforts 
>>> you can put in at compile time
>> 
>> That is a fact back by some interesting papers.
> 
> It would be interesting if this is practical or a theoretical you could, but 
> would you? Can such a compiler exist and if it does what is preventing it 
> from being the standard way we build software with? Recursion only languages 
> are possible and a fact too. Do you have some links btw?
> 
> All the magic comes with a price ;), what is the price of only relying on 
> static code analysis? How much do we pay in productivity? Nothing is free.

Runtime optimization beats compiler hands down on long running code. Don't 
think swift will ever be as good as java on servers, but I don't think it is 
their target either, so all's well. I wish google would fork swift next year to 
make it more credible on servers. Don't get me wrong, swift is great.. as a 
successor to objc. I had high hopes when it came out, but at the moment i take 
far more pleasure in writting generic code in typescript. This is quite 
disapointing so far, and 3 is just differently unfinished than 2 was, but not 
fundamentally enhanced.

> 
> How much would we pay in performance if one day the CPU takes the same 
> approach and throws branch predictors, prefetchers, register renaming and 
> reorder buffers, store-load forwarding, etc... (I am also insanely convinced 
> that given proper funds and a modern manufacturing process IA-64 had a chance 
> to prove itself and kick some ass ;))

At what power cost?  In the end arm is showing that simplicity works.


> and we have another go at VLIW?
> 
>> By it is also true that one cannot always be used in place of the other.
>> 
>>> ... unless that work essentially replaces the runtime. Do we want to help 
>>> coders with a great compiler and static analysis tools? Yes! Do we need to 
>>> castrate the runtime to achieve this making it physically impossible for 
>>> developers to escape the controlled environment we strictly want them to 
>>> live in? I do not think so and we may regret the results once everything 
>>> including UI and app frameworks are all Swifty™ (it is starting to get 
>>> marketing firm icky when a discussion is stopped when this word is invoked 
>>> or inflamed by a disagreement on who is more swiftly orthodox). I think 
>>> that without holding technology back due to fear, we should not proceed 
>>> only with the assumption that old way == worst thing ever  while  new way 
>>> == it is new and young, it must be good.
>>> 
>>> Objective-C did not survive and thrive in Cocoa for so many years 
>>> completely in spite of its many many deficiencies as sometimes it seems on 
>>> this list (Objective-C being put down more than necessary IMHO... Swift 
>>> does not need this kind of sometimes slightly biased comparison to be 
>>> appreciated in full, but it can stand on its own merits). 
>>> 
>>> Maybe the reason we like Cocoa/Cocoa Touck/AppKit/UIKit/etc... is precisely 
>>> because of the beautiful balance it strikes between (sometimes leaning more 
>>> on developers opting-in) safety and versatility allowing good code to be 
>>> produced and tested quickly thus allowing easier prototyping, refactoring, 
>>> and iterative development.
>>> 
>>> Sorry for the even more off topic bit and thank you to those people who 
>>> read this.
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPhone
> 
>> 
>> Cocoa currently hides the boilerplate for all of these wonderful constructs 
>> behind amazingly effective runtime acrobatics. This fits perfectly into 
>> Objective-C, and it also works very well in Swift. But such features could 
>> be in better harmony with Swift's unique set of language constructs if their 
>> boilerplate was hidden behind amazingly effective **compile-time** 
>> acrobatics instead.
>> 
>> Such compile-time acrobatics are hard to perform today, and it is possible 
>> that the ability to create such systems will forever remain an advanced 
>> skill, just like forging runtime magic requires advanced skills in 
>> Objective-C.
> 
> ... rantish...
> 
> I am still not convinced that even the best compiler can fully replace what a 
> powerful runtime can provide no matter the acrobatics you put in in terms of 
> compiler introduced utility code/constructs or the code analysis efforts you 
> can put in at compile time

That is a fact back by some interesting papers. By it is also true that one 
cannot always be used in place of the other.

> ... unless that work essentially replaces the runtime. Do we want to help 
> coders with a great compiler and static analysis tools? Yes! Do we need to 
> castrate the runtime to achieve this making it physically impossible for 
> developers to escape the controlled environment we strictly want them to live 
> in? I do not think so and we may regret the results once everything including 
> UI and app frameworks are all Swifty™ (it is starting to get marketing firm 
> icky when a discussion is stopped when this word is invoked or inflamed by a 
> disagreement on who is more swiftly orthodox). I think that without holding 
> technology back due to fear, we should not proceed only with the assumption 
> that old way == worst thing ever  while  new way == it is new and young, it 
> must be good.
> 
> Objective-C did not survive and thrive in Cocoa for so many years completely 
> in spite of its many many deficiencies as sometimes it seems on this list 
> (Objective-C being put down more than necessary IMHO... Swift does not need 
> this kind of sometimes slightly biased comparison to be appreciated in full, 
> but it can stand on its own merits). 
> 
> Maybe the reason we like Cocoa/Cocoa Touck/AppKit/UIKit/etc... is precisely 
> because of the beautiful balance it strikes between (sometimes leaning more 
> on developers opting-in) safety and versatility allowing good code to be 
> produced and tested quickly thus allowing easier prototyping, refactoring, 
> and iterative development.
> 
> Sorry for the even more off topic bit and thank you to those people who read 
> this.
> ___
> 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] Qualified Imports and Modules

[L. Mihalkovic via swift-evolution]

Import Foo.* as bar.// has public methodX() and type TypeA
Import Foo2.* as baz. // also has public methodX() and type TypeA

would be interesting because it entirely avoids collisions when using both 
together. It also provides some documentation at the point of use, as well as 
allow the IDE to keep its indexing of Foo completely distinct fromthe indexing 
of the current module. The last point is that it also leads to less cluttered 
code completion proposal lists

Y = bar.methodX() + baz.methodX()
var v1 = new bar.TypeA()
var v2 = new baz.TypeA()


Regards
(From mobile)

> On Jul 19, 2016, at 6:50 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> My gut feeling is also that this is more complex than it needs to be. If we 
> want to keep all of these features around, I'd be in favor of looking for a 
> syntax that "flows better" than three separate clauses.
> 
> Also, under the current model (or a somewhat recent model, because I ran into 
> that last month), everything included in a bridging header is implicitly 
> imported into every Swift file. If it #includes Foundation, you won't get to 
> refine that from Swift. The proposal would probably benefit from taking that 
> into account, somehow. (Allow re-imports? Separate module imports from 
> using-like statements?)
> 
> Finally, should selecting extension methods with the same name or 
> conformances to the same protocol from different modules be considered a 
> problem that this proposal intends to solve?
> 
> Félix
> 
>> Le 18 juil. 2016 à 18:19:59, Joe Groff via swift-evolution 
>>  a écrit :
>> 
>> Our import story definitely needs work, and this is a step in the right 
>> direction. Thanks for working on this! Some comments:
>> 
>> - The import changes can be separated from the submodule issues. Enhancing 
>> imports is IMO more important, and is source-breaking today, whereas 'module 
>> ' declarations and submodules can be added later. I'd suggest breaking this 
>> into two proposals.
>> - I think the `import` design you propose is a bit more complicated than it 
>> needs to be. Python and Haskell get by just having "import everything" and 
>> "import itemized (with aliases)". I don't see the need for 'hiding'; if you 
>> have a rule that itemized imports get priority over import-everything, then 
>> that covers the most important use case of selectively shadowing one 
>> module's imports with another. Bikeshed-wise, I don't see much reason to 
>> veer from the Java/Haskell-ish template of:
>> 
>> import Foo.* // import everything from module Foo
>> import Foo.(x, y, z as zed) // import x, y, and z from foo, renaming Foo.z 
>> to zed
>> 
>> -Joe
>> 
>>> On Jul 18, 2016, at 2:09 PM, Robert Widmann via swift-evolution 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework 
>>> qualified imports and introduce an explicit module system to Swift that 
>>> we’d like to publish for your viewing pleasure.
>>> 
>>> The initial impetus was set out in a radar (rdar://17630570) I sent fairly 
>>> early on that didn’t receive a response, so I started a swift-evolution 
>>> thread discussing the basics of this proposal.  It has been refined and 
>>> expanded a bit to include an effort to make Swift modules explicit and 
>>> updated with the feedback of that first thread.  Contents of the proposal 
>>> are inline and can also be had as a gist or on Github.
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> Qualified Imports and Modules
>>> 
>>> • Proposal: SE-
>>> • Authors: Robert Widmann, Harlan Haskins, TJ Usiyan
>>> • Status: Awaiting review
>>> • Review manager: TBD
>>> Introduction
>>> 
>>> We propose a complete overhaul of the qualified imports syntax and 
>>> semantics and the introduction of a module system.
>>> 
>>> Motivation
>>> 
>>> Swift code is modular by default. However, it is not clear how to decompose 
>>> existing modules further into submodules. In addition, it is difficult to 
>>> tell how importing a module affects its export to consumers of a library. 
>>> This leads many to either fake namespaces with enums, attempt to structure 
>>> Swift code with modulemaps, or use a large amount of version-control 
>>> submodules. All of these can be rolled into one complete package in the 
>>> form of a comprehensive rethink of the qualified import system and the 
>>> introduction of a module system.
>>> 
>>> Proposed solution
>>> 
>>> Modules will now become an explicit part of working with canonical Swift 
>>> code. The grammar and semantics of qualified imports will change completely 
>>> with the addition of import qualifiers and import directives. We also 
>>> introduce three new contextual keywords: using, hiding, and renaming, to 
>>> facilitate fine-grained usage of module contents.
>>> 
>>> Detailed design
>>> 
>>> Qualified import syntax will be revised to the 

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

[L. Mihalkovic via swift-evolution]

Interesting... mix of c# and swift and others

I am not sure it has many chances to see the light: unless they internally 
manage to cheat and reuse the natural scoping provided by empty enums, the 
implications on the binary structure of the dylibs are kolossal... and as if 
this was not enough, there will be a similar impact on the linux runtime. If 
memory serves, the last issues standing in the way for a windows port were just 
recently overcome (same business of how to store the runtime data into the 
structure of a dll), and this would send them back a few steps back.
Considering this is v3.0, the last of the breakers, and this is the very end of 
the cycle, with features still not designed as well as designs without coders, 
I think that a deep change like this one is rather unlikely for 3, and unless 
there is a clever way to make it additive in 4, then ever. Had swiftc been 
written in swift 4 years ago, this is likely one of the first things the core 
team would have missed, to deal with a 150,000+ loc codebase (i think in wwdc 
someone threw 500k as the total size today - the typescript type checker is 
~20kloc).
But i still hope some variations on the theme will show up (preferably as 
somthing like the less verbose "using  as v"  "using x omitting 
bb" "using (b) from x")

Regards
(From mobile)

> On Jul 18, 2016, at 11:09 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hello all,
> 
> TJ Usiyan, Harlan Haskins, and I have been working on a proposal to rework 
> qualified imports and introduce an explicit module system to Swift that we’d 
> like to publish for your viewing pleasure.
> 
> The initial impetus was set out in a radar (rdar://17630570) I sent fairly 
> early on that didn’t receive a response, so I started a swift-evolution 
> thread discussing the basics of this proposal.  It has been refined and 
> expanded a bit to include an effort to make Swift modules explicit and 
> updated with the feedback of that first thread.  Contents of the proposal are 
> inline and can also be had as a gist or on Github.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Qualified Imports and Modules
> 
> Proposal: SE-
> Authors: Robert Widmann, Harlan Haskins, TJ Usiyan
> Status: Awaiting review
> Review manager: TBD
> Introduction
> 
> We propose a complete overhaul of the qualified imports syntax and semantics 
> and the introduction of a module system.
> 
> Motivation
> 
> Swift code is modular by default. However, it is not clear how to decompose 
> existing modules further into submodules. In addition, it is difficult to 
> tell how importing a module affects its export to consumers of a library. 
> This leads many to either fake namespaces with enums, attempt to structure 
> Swift code with modulemaps, or use a large amount of version-control 
> submodules. All of these can be rolled into one complete package in the form 
> of a comprehensive rethink of the qualified import system and the 
> introduction of a module system.
> 
> Proposed solution
> 
> Modules will now become an explicit part of working with canonical Swift 
> code. The grammar and semantics of qualified imports will change completely 
> with the addition of import qualifiers and import directives. We also 
> introduce three new contextual keywords: using, hiding, and renaming, to 
> facilitate fine-grained usage of module contents.
> 
> Detailed design
> 
> Qualified import syntax will be revised to the following
> 
> module-decl -> module 
> import-decl ->  import  <(opt) 
> import-directive-list>
> module-path -> 
> -> .
> import-directive-list -> 
>   ->  
> import-directive -> using (, ...)
>  -> hiding (, ...)
>  -> renaming (, to: , ...)
> This introduces the concept of an import directive. An import directive is a 
> file-local modification of an imported identifier. A directive can be one of 
> 3 operations:
> 
> 1) using: The using directive is followed by a list of identifiers within the 
> imported module that should be exposed to this file. 
> 
> // The only visible parts of Foundation in this file are 
> // Date.init(), Date.hashValue, and Date.description.
> import Foundation.Date using (Date.init(), Date.hashValue, Date.description)
> 2) hiding: The hiding directive is followed by a list of identifiers within 
> the imported module that should be hidden from this file.
> 
> // Imports all of Foundation.Date except `Date.compare()`
> import Foundation.Date hiding (Date.compare())
> 3) renaming: The renaming directive is followed by a list of identifiers 
> separated by to: that should be exposed to this file but renamed. 
> 
> // Imports all of Dispatch.DispatchQueue but renames the static member 
> // DispatchQueue.main, to DispatchQueue.mainQueue
> import Dispatch.DispatchQueue renaming (DispatchQueue.Type.main to: 
> DispatchQueue.Type.mainQueue)
> // Renaming can also rename modules.  All members 

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 18, 2016, at 9:43 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> 
>> On Mon, Jul 18, 2016 at 12:28 PM, Johannes Neubauer via swift-evolution 
>>  wrote:
>> Dear Xiaodi,
>> 
>> > Am 18.07.2016 um 20:55 schrieb Xiaodi Wu :
>> >
>> > As mentioned earlier, NaN != NaN, demonstrating that an Equatable instance 
>> > that does not always equal itself is not "radical." Plainly, your proposal 
>> > is unworkable.
>> 
>> 1. this is a basic internal type, so it can have a special behavior, since 
>> it is a well-designed data type created by the language designers (since 
>> there is no need to bootstrap swift from the first bits this is OK).
> 
> The problem is that this is *exactly* how Swift works. There is nothing 
> special about e.g. Double except for the fact that it wraps a built-in type 
> and the implementation of its operations forward to built-in functions. This 
> is how all the stdlib types work. You can build your own refcounted COW 
> `Array` with exactly no additional compiler support from scratch, if you want.

Well, there is something special.. The fact that the compiler will to the 
forwarding, and not not do something equivalent for other data types.


> 
>  
> 
> 
>  
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution 
>  wrote:
> 
> If people were generally happy with having public members of open classes 
> overridable by default, then we certainly wouldn't need to have a separate 
> qualifier for that. (Although as "internal" demonstrates, it's nice to have a 
> formal name for such things.)
> 
> 
> 
> However, (1) having a default would allow API designers to define public APIs 
> with very little additional thought, and (2) it seems to me we're very very 
> far from consensus on which default would be best. I'd like to avoid arguing 
> even more about the theoretical merits of choosing open vs final vs dynamic 
> by default. (Note that there are highly respectable app developers who 
> honestly consider "open" much too restricting.)
> 
> 
> 
> I'm enthusiastic about sealed-by-default classes, but to be honest, I 
> personally have no idea what default (if any) would be best for class 
> members. Ask me again after I've worked with the new classes for a couple of 
> months.
> 
This is what i find so unique about this situation: there is not 2 months to 
decide, there is not a couple of implementations to compare.. there is here and 
now to decide for the next 20 years, with zero experience with the api and very 
little external references (which nobody seems to have sahed any practical 
experience with) ... nonetheless it must all be fleshed out before the 28th. I 
cincerely hope the core team is more prepared than they currently let out.


> 
> Karoly
> 
> @lorentey
> 
> 
> 
> On 2016-07-18 18:45:14 +, Nevin Brackett-Rozinsky via swift-evolution 
> said:
> 
> 
> 
> Garth makes an excellent point. Károly is correct that we can already achieve 
> “sealed” by making a `final` member call through to an `internal` one.
> 
> 
> 
> Therefore, it seem clear that “open” should only be applicable to classes, 
> not to members. This should simplify the proposal nicely.
> 
> 
> 
> Nevin
> 
> 
> 
> 
> 
> On Mon, Jul 18, 2016 at 2:39 PM, Garth Snyder via swift-evolution 
>  wrote:
> 
> > Károly wrote: I suggest we change the proposal to remove the implicit 
> > "sealed" level of public member overridability, and support only "open" or 
> > "final" class members. For members, "open" should mean the opposite of 
> > "final", with no levels in between. Member-level openness should be 
> > entirely independent of visibility; so it should be possible to say 
> > "internal open" to mean an internally overridable member that's not at all 
> > visible outside the module -- the same as today's default.
> 
> 
> 
> What is the distinction between this approach and simply omitting the ability 
> to apply the “open” keyword to anything but a class?
> 
> 
> 
> The current behavior is (IIUC) that you cannot override a superclass’s final 
> method. Aside from that, you can override any other method that’s visible to 
> you, wherever you stand with regard to the superclass’s origin. If there’s no 
> sealed status for members, why is any change to member annotations needed at 
> all?
> 
> 
> 
> Garth
> 
> ___
> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jul 18, 2016, at 7:12 PM, John McCall via swift-evolution 
 wrote:

>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution 
>>  wrote:
>> I disagree that an `open` method overridden from a superclass is implicitly 
>> `open`.
>> 
>> As the rationale for the proposal states, overridability is hard to get 
>> right, and there is no guarantee that the consumer of an API is going to 
>> think about it. The default for override methods should not be `open` or 
>> `final`, it should be the internal equivalent.
>> 
>> A coder subclassing a public API, who themselves wants their subclass to be 
>> subclassable, should need to restate `open` where appropriate.
> 
> I don't think that defaulting to non-open would be a good idea.  Like I 
> covered in the proposal, inherited open methods remain open; letting an 
> override implicitly close off an open method would create a pretty 
> unfortunate error-of-omission situation.
> 
> We could remove the default here and require the method to be explicitly 
> open/nonopen/final, but then we really do pile up the modifiers:
> 
>  public open override func foo()
> 
> To me, the fact that it's already marked with "override" suggests the 
> possibility of open-ness enough to remove the need to re-state it.  I can see 
> why you might disagree, though.

the fact that someone thought that something could be extended does not imply 
that the one who extended it also carefully planed for her own code to be 
extensible... and even if one particular method A which was declared extensible 
has not been altered directly in a subclass, through extending others that are 
related and not having planned carefully the interplay, method A may have now 
been rendered unfit for further extension. 

So simply as a matter of following the logic of the proposal, every subsequent 
extension of something explicitely marked as open for subclassing should 
defacto be placed back into the default non-subclassable state, forcing the 
author to have to explicitely validate the new set of relationships existing 
between the methods in the subclass. Otherwise the logic does not hold, and the 
original proposal does not hold water: that which cannot be assumed as safe on 
level 0, cannot be suddenly assumed safe at level 1 of subclassing, because the 
outer API surface of level-n subclasing forms no more implicite guaranty of 
soundness than existed at level n-1. The proposal is all about the fact that it 
is the developer who MUST PROVIDE the soundness guaranty.


> 
> John.
> 
>> 
>> This also seems to be a general conflict in that you can always reduce the 
>> access, e.g. an API might have a `public open` method, but the subclass 
>> should be able to declare that as `override private` and thus the `open` 
>> keyword would be invalid in this context.
>> 
>> 
>> Scott
>> ___
>> 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] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[L. Mihalkovic via swift-evolution]

IMHO implementing your proposal would close the door on some of the things you 
do when building in-memory dbs (T == U -> TRUE for T not related to U), which 
if swift remains for small apps is not a terrible loss, but may be more of an 
issue for one day doing big-data with it.

Regards
(From mobile)

> On Jul 18, 2016, at 12:21 PM, Johannes Neubauer via swift-evolution 
>  wrote:
> 
> See below...
> 
>> Am 18.07.2016 um 12:08 schrieb Johannes Neubauer via swift-evolution 
>> :
>> 
>> Dear  Félix,
>> 
>> As a small follow-up, because you asked what I am protecting you from. 
>> Dictionaries and Sets, for instance, will work only, if equality and hash 
>> value are computed contract conform. As soon as you let (unintendedly) 
>> differing values collapse or same values break up, you will have unintended 
>> behavior. This is crucial and I think every developer should be thankful for 
>> any help he gets here from a language. If (in the future) the swift runtime 
>> will create value pools for you, and you have a wrong implementation of 
>> equality, the complete system will just misbehave. **That** will be bugs 
>> hard to find.
>> 
>> All the best
>> Johannes
>> 
>>> Am 18.07.2016 um 11:50 schrieb Johannes Neubauer via swift-evolution 
>>> :
>>> 
>>> 
 Am 18.07.2016 um 03:51 schrieb Félix Cloutier :
 
 Your initial rationale no longer makes sense with your suggested solution. 
 If the dumb comparison returns false, people can still introduce side 
 effects in the comparison method, except that now it's even harder to find 
 out because all of my equality tests have been rewritten as "memcmp(a, b) 
 || ==(a, b)“.
>>> 
>>> No its `memcmp(a, b) && ==(a,b)`, since if the „standard equality“ says 
>>> `true` there is no short-circuit, but the custom implementation has to be 
>>> `true` either! It is just a pre-condition.
> 
> Sorry, wrote this in a hurry. It is `||` of course. But still the rest holds.
> 
>>> 
 What are you trying to protect me from?
>>> 
>>> 1. You cannot say something is unequal although the system says it is equal
>>> 2. You do not have to implement equality for value types, only if you 
>>> really need custom behavior (so you do not write boiler-plate code, which 
>>> is error prone), so side effects will be less common
>>> 3. With unique indirect storage (and copy-on-write) you would be able use 
>>> `==` for large values, because these values are only shared for reads not 
>>> for writes  (future, not yet available in swift), so no race conditions
>>> 4. With `dispatch` in operator-methods (or any other) as well as a 
>>> `default` clause for reference types, so that equality of mixed-types just 
>>> result in `false`, so that this is not possible anymore (see excerpt of 
>>> discussion):
>>> 
 Am 16.07.2016 um 15:18 schrieb Johannes Neubauer via swift-evolution 
 :
 
 This is not true for reference types. Consider the following **bad** (but 
 compiling code):
 
 ```swift
 class A: Equatable {}
 
 class Aa: A {
 let a: Int
 
 init(a: Int) {
 self.a = a
 }
 }
 
 func ==(lhs: A, rhs: A) -> Bool {
 return lhs === rhs
 }
 
 func ==(lhs: Aa, rhs: Aa) -> Bool {
 return lhs.a == rhs.a
 }
 ```
 
 Now let us use this:
 
 ```swift
 let a = A()
 let a2 = A()
 let aa = Aa(a: 0)
 let aa2 = Aa(a: 1)
 let aa3 = Aa(a: 1)
 
 // prints `true`
 print(a == a)
 
 // prints `false`
 print(a == a2)
 
 // prints `false`
 print(a == aa)
 
 // prints `false`
 print(a == aa3)
 
 // prints `false`
 print(aa == aa2)
 
 // prints `true` because it compares the `a: Int` values.
 print(aa2 == aa3)
 
 // now mixed-type comparison (returns `false`)
 print(a == aa2)
 ```
 
 Hence, you can do mixed-type equality checks in Swift. Even worse is, you 
 can do this:
 
 ```swift
 let aa2AsA: A = aa2,
 aa3AsA: A = aa3
 
 // prints `true` because it compares the `a: Int` values.
 print(aa2 == aa3)
 
 // prints `false`, because the equals method of `A` is used
 print(aa2AsA == aa3AsA)
 ```
 
 Just by assigning an object to a variable that is typed differently the 
 result is completely different. This is because method parameters are 
 dispatched statically. This is fast, but results in really unintended 
 results, you can do a **lot** of things breaking the contract of `==` with 
 that. This is why I wanted to add a `default` clause (in *3.* of my 
 original proposal) for such methods involving two references to `Self`. 
 Further on, I wanted to add the keyword `dispatch` for method (and 
 operator) parameters, where dispatching is necessary (see *2.* of my 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon <br...@architechies.com> wrote:

>> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Is there a summary somewhere of the motivation for allowing methods to be 
>>> declared non-overridable within open classes?
>> 
>> Because 1) someone woke up one morning and thought it would be great 2) it 
>> goes into the direction of making swift a language for non programmers 3) 
>> the core team wants it
> 
> Laurent: This is not a fair characterization of the actual position of the 
> proposal's supporters. If you can't be civil about this topic, perhaps you 
> shouldn't be discussing it at all.

It was not my intention to depict the intentions of the community but simply to 
state a couple facts. 1) Some proposal are born out of the evolution of another 
proposal, while others evolve as a subset of something more complex that needs 
to be broken down. This one did not, and was simply presented one morning. 2) 
The wwdc this year was very clear on the fact that one of the goals of the 
platform via swift is to put the language into the hands of non-professional 
programmers. The video was very well done and very inspirational. The new ipad 
playground app is a key part of this strategy, the other one being the 
language. The language has undergone great simplifications since the days of 
1.xx with advanced features like tupple splatting or currying now removed, and 
confusing naming or constructs also gradually removed (3.0 is a very big step 
in ghat direction). 3) the core team was very clear that it is the direction 
they want for the language.

> Garth: I think it's implicit in the reasons to prevent subclassing. The mere 
> fact that a class allows subclassing doesn't necessarily mean that every 
> member in it is designed to be subclassed. Consider `UIViewController`: It's 
> obviously designed to be subclassed, and some methods in it (such as 
> `loadView`) are intended to be overridden, but others (such as 
> `loadViewIfNeeded`) are *not* intended to be overridden.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution 
>  wrote:
> 
> Is there a summary somewhere of the motivation for allowing methods to be 
> declared non-overridable within open classes?
> 
> I’m not asking about any particular syntax or default, just why you'd want 
> this facility at all. The proposal doesn’t mention this, and the discussion 
> of the initial version never really seemed to reach the issue, either.
> 
> I can see that there’s a potential for static dispatch on non-overridable 
> methods when called from outside the module. But presumably there’s an 
> architectural argument in favor of this restriction as well.

Because 1) someone woke up one morning and thought it would be great 2) it goes 
into the direction of making swift a language for non programmers 3) the core 
team wants it


> 
> Garth
> 
> ___
> 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-0119: Remove access modifiers from extensions

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Wrong thread ;) If you think it’s ill-prepared than provide some feedback 
> instead of just watching and waiting to throw negative feedback during review 
> process.
> 
> There is a lot done, but it’s not visible to the public thread yet. Will be 
> soon (by tomorrow I’d guess).
> 
> Thanks.
> 

A question i regularly ponder on with modern opensource is how it went so fast 
from stallman writting gcc to today's anything-goes, where there seems to be an 
expectatation that throwing even the worst unfinished piece of code in the 
public should implicitely gag others, and only compel them to have to fix it. 
There has always been great as well as ludicrous ideas in the history of 
mankind, and it would be a rare privilege of the opensource movement that the 
latter ought not to be singled out as such, and have them become by their mere 
presence in the public, everyone's responsibility to improve upon. 
This proposal was based on a lack of understanding of extensions. My understand 
of the process is that the initial discussion phase is there to evaluate an 
idea leaving, only the promissing ones reach proposal stage.
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 16. Juli 2016 um 21:21:59, L. Mihalkovic (laurent.mihalko...@gmail.com) 
> schrieb:
> 
>> To me this is reminicent of what is happening with the T.Type / Type 
>> story, where there seems to be a rush to throw a proposal under the cut-off 
>> date even if it is ill-prepared, or based on misunderstandinds.
>> Regards
>> (From mobile)
>> 
>> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>>> I tried to tackle the ability to write extensions where everyone would be 
>>> forced to write access modifier on member level. That’s what I had in my 
>>> mind all the time. But the respond on this was, as you can see purely 
>>> negative. :D
>>> 
>>> Making all extensions public when there is protocol conformance makes no 
>>> sense, because you could extend your type with an internal protocol, or the 
>>> extended type might be not public.
>>> 
>>> Anyways, I’m withdrawing this proposal. :)
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:
>>> 
 Because of all this, I have stopped using extension-level access modifiers 
 altogether, instead always specifying access at the member level. I would 
 be interested in a proposal to improve the current model — perhaps, for 
 example, making “public extension” apply only to a protocol conformance, 
 and disabling access modifiers on extensions that don’t have a protocol 
 conformance.
>>> ___
>>> 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 #2] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 17, 2016, at 4:24 AM, L. Mihalkovic  
> wrote:
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of "SE-0117: Default classes to be non-subclassable 
>> publicly" begins now and runs through July 22. 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?
> 
> Part of a series of increasingly compelling arguments for switching other 
> languages for writting ios/osx application, provided that that is not also 
> prohibited in the various stores in the near future
> 
>>   * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> No. I'll self censor the rest as it is not flatering

The jist is that, as demonstrated by the discussions in the original thread, 
the proposal as it is worded is incomplete, paving the way to a 0111 scenario 
if rushed to approval as is. 

> 
>>   * Does this proposal fit well with the feel and direction of Swift?
> 
> Feel: not surewhat the feel of swifft is supposed to be anymore
> Direction: yes... training wheels all around, limited abilitiy to organize & 
> structure code (other key features missing for that & plenty of real life 
> examples on github to show this is actually the case)
> 
>>   * If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> The bulk my professional experience has been mostly with asm x86, c, c++, 
> perl, java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and 
> recently TypeScript. None have something equivalent. I recently started 
> toying with kotlin, that looks at inheritence in a similar light, but do not 
> have enough real life experience yet to speak.
> As for TypeScript, I only recently started writing large amounts of it 
> professionally, and I am absolutely blown away: it has been the easiest 
> language to learn and become extremely productive with, thanks to the most 
> sound generic type system I have ever used (for bkgrnd, I love and makes very 
> heavy use of the java/c# generics). 
> 
>>   * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> A lot.
> 
>> 
>> 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

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The second review of "SE-0117: Default classes to be non-subclassable 
> publicly" begins now and runs through July 22. 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?

Part of a series of increasingly compelling arguments for switching other 
languages for writting ios/osx application, provided that that is not also 
prohibited in the various stores in the near future

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

No. I'll self censor the rest as it is not flatering

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

Feel: not surewhat the feel of swifft is supposed to be anymore
Direction: yes... training wheels all around, limited abilitiy to organize & 
structure code (other key features missing for that & plenty of real life 
examples on github to show this is actually the case)

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

The bulk my professional experience has been mostly with asm x86, c, c++, perl, 
java, scala, tcl/tk, go, xtend, vb, c#, fortran, cobol, javascript and recently 
TypeScript. None have something equivalent. I recently started toying with 
kotlin, that looks at inheritence in a similar light, but do not have enough 
real life experience yet to speak.
As for TypeScript, I only recently started writing large amounts of it 
professionally, and I am absolutely blown away: it has been the easiest 
language to learn and become extremely productive with, thanks to the most 
sound generic type system I have ever used (for bkgrnd, I love and makes very 
heavy use of the java/c# generics). 

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

A lot.

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

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

[L. Mihalkovic via swift-evolution]

To me this is reminicent of what is happening with the T.Type / Type story, 
where there seems to be a rush to throw a proposal under the cut-off date even 
if it is ill-prepared, or based on misunderstandinds.
Regards
(From mobile)

> On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I tried to tackle the ability to write extensions where everyone would be 
> forced to write access modifier on member level. That’s what I had in my mind 
> all the time. But the respond on this was, as you can see purely negative. :D
> 
> Making all extensions public when there is protocol conformance makes no 
> sense, because you could extend your type with an internal protocol, or the 
> extended type might be not public.
> 
> Anyways, I’m withdrawing this proposal. :)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 16. Juli 2016 um 19:09:09, Paul Cantrell (cantr...@pobox.com) schrieb:
> 
>> Because of all this, I have stopped using extension-level access modifiers 
>> altogether, instead always specifying access at the member level. I would be 
>> interested in a proposal to improve the current model — perhaps, for 
>> example, making “public extension” apply only to a protocol conformance, and 
>> disabling access modifiers on extensions that don’t have a protocol 
>> conformance.
> 
> ___
> 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] adding Obj-C syntax to Swift?

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution 
>  wrote:
> 
> My reply didn’t go to the list… my apologies…
> 
> On Jul 11, 2016, at 8:19 PM, Ford Prefect 
> > wrote:
> 
> People say nearly every WWDC code example was Swift. That says to newcomers 
> "learn Swift, not Obj C".
> Swift is being ported on other platforms but Objective C is not.
> Google has talked about switching to it, which may be unrelated but likely 
> not since the Valley is a small place.
> 
> More people using Swift is great. But C is still used. C++ is used. Why does 
> Obj-C need to go away for Swift to gain a larger dev base?
> 
> If Google starts to use Swift, do you see Java going away?

As of 2 years ago the google source code repo had more than 10Mloc of java. It 
might take a while to replace. Assuming they would adopt swift for android, i 
give it no more than 2 years for them to come with a fork having all the 
type-system enhancements apple does not want to add, in the spirit of how they 
did to the webkit code some of the refectoring the apple team did not want to 
do (i remember when they did the reorg many wanted or introduced the out of 
proc loading model first)

> 
> Obj-C has been here for awhile. Certainly before iOS and even before OS X. I 
> don’t see it going away any time soon, even in those eco-systems.
> 
> Best,
> 
> Josh
> 
> 
> Sent: Monday, July 11, 2016 at 8:03 PM
> From: "Josh Parmenter" 
> >
> To: "Ford Prefect" >
> Subject: Re: [swift-evolution] adding Obj-C syntax to Swift?
> Where is this wall with writing you speak of?
> My feeling is, if you want Obj-C syntax, why not use Obj-C? I actually don't 
> get the feeling that access to it as a development language is really going 
> away.
> Best
> Josh
> 
> Sent from my iPhone
> 
> On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution 
> >
>  wrote:
> 
> Perhaps one of the most disliked aspects of Swift
> is the Rust-like syntax, which requires that each coder resign himself to
> grin-and-bear-it in order to obtain the benefits of Swift.
> Since "the writing is on the wall" that Objective C
> is in its last days at least as far as app writers go
> (maybe within Apple it will endure), is there any
> chance of sweetening the pill a bit by giving us
> back the more readable syntax of Objective C, in particular
> the method call syntax? It just made more sense to
> format a method call like Smalltalk.
> ___
> 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] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 15, 2016, at 8:26 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>>> On Jul 14, 2016, at 10:58 PM, Charles Srstka  
>>> wrote:
>>> 
>>> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> - Second is that clients of some other public API vended by a non-Apple 
>>> framework (e.g. a SwiftPM package) may end up in a situation where the 
>>> framework author didn’t consider subclass-ability, but the client desires 
>>> it.  In this situation, the core team feels that a bigger problem happened: 
>>> the vendor of the framework did not completely consider the use cases of 
>>> the framework.  This might have happened due to the framework not using 
>>> sufficient black box unit testing, a failure of the imagination of the 
>>> designer in terms of use cases, or because they have a bug in their 
>>> framework that needs unanticipated subclass-ability in order to “get a job 
>>> done”.
>> 
>> Or because the framework was developed in the real world, rather than 
>> Elysium, and real-world framework developers just about *never* anticipate 
>> every single way someone might use their framework (Indeed, if developers 
>> were capable of such a thing, there would be no need for third-party 
>> software in the first place).
> 
> I’m not sure what you’re trying to say.  I agree that it is clearly the case 
> that a framework author cannot anticipate every single use case of their 
> framework.  
> 
> However, it is just as clearly the case that “unanticipated subclassability” 
> isn’t a general solution to that problem.

I think seeing it as 'clear' is pure perspective, rather than fact. For 
instance it might ba apple's perspective, but not red hat's (consider that it 
took 10 years to be able to delete apps from our devices... indicating that 
from apple's view point there seems to be a mindset that we cannot do things 
opportunistically, assuming the consequences of our choices, which does exist 
in others parts of the technology planet).

> 
> -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] [Discussion] Seal `T.Type` into `Type`

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 13, 2016, at 2:02 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> This isn’t a full proposal (yet). We still can change things. I didn’t 
> consider everything and can’t to that on my own. Feedback is welcome.
> 
> To answer your question, we still need the metatype to access initializer and 
> static member of that type. If we’d drop T.Type completely, we’d lose 
> functionality to do so.
> 
> protocol A {
> init()
> }
> 
> func foo(metatype: T.Type) -> T {
> return metatype.init()
> }
> The downside of this proposal is the bottleneck property to access that 
> functionality, otherwise adding Hashable or other things like size 
> (MemoryLayout) won’t be possible without serious compiler magic. So do I 
> believe.
> 
> func foo(type: Type) -> T {
> return type.metatype.init()
> }
> This is huge tradeoff, but it’s worth considering if the community can life 
> with that.
> 
> Furthermore as already been mentioned in this thread, we might consider to 
> extend Type to add reflection functionality to it. (If we’d decide to go 
> in that direction.)
> 
IMHO it is not just a matter of 'adding reflection'.. this IS a subset of 
reflection. The key is to design it question exhaustively enough to leave clean 
holes for the rest being only additive. Otherwise this will lead the way to 
more 'oops we have to change the proposal so that what we loose now can be put 
back additively later' (reference to the recent dance around the labels in sigs 
proposal that had to be patched post-acceptance)



> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Juli 2016 um 13:15:02, Anton Zhilin (antonyzhi...@gmail.com) schrieb:
> 
>> Why can't we drop metatypes T.Type with your proposal? Do they bring some 
>> extra capabilities over Type struct? 
> 
> ___
> 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] adding Obj-C syntax to Swift?

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution 
>  wrote:
> 
> My reply didn’t go to the list… my apologies…
> 
> On Jul 11, 2016, at 8:19 PM, Ford Prefect 
> > wrote:
> 
> People say nearly every WWDC code example was Swift. That says to newcomers 
> "learn Swift, not Obj C".
> Swift is being ported on other platforms but Objective C is not.
> Google has talked about switching to it, which may be unrelated but likely 
> not since the Valley is a small place.
> 
> More people using Swift is great. But C is still used. C++ is used. Why does 
> Obj-C need to go away for Swift to gain a larger dev base?
> 
> If Google starts to use Swift, do you see Java going away?

It opens some interesting lines of thinking... Will google eventually become 
"the future of swift"? I would not be entirely surprised considering the 
man-power they have compared to apple, what they already did in the past in 
similar situations.

> 
> Obj-C has been here for awhile. Certainly before iOS and even before OS X. I 
> don’t see it going away any time soon, even in those eco-systems.
> 
> Best,
> 
> Josh
> 
> 
> Sent: Monday, July 11, 2016 at 8:03 PM
> From: "Josh Parmenter" 
> >
> To: "Ford Prefect" >
> Subject: Re: [swift-evolution] adding Obj-C syntax to Swift?
> Where is this wall with writing you speak of?
> My feeling is, if you want Obj-C syntax, why not use Obj-C? I actually don't 
> get the feeling that access to it as a development language is really going 
> away.
> Best
> Josh
> 
> Sent from my iPhone
> 
> On Jul 11, 2016, at 20:00, Ford Prefect via swift-evolution 
> >
>  wrote:
> 
> Perhaps one of the most disliked aspects of Swift
> is the Rust-like syntax, which requires that each coder resign himself to
> grin-and-bear-it in order to obtain the benefits of Swift.
> Since "the writing is on the wall" that Objective C
> is in its last days at least as far as app writers go
> (maybe within Apple it will endure), is there any
> chance of sweetening the pill a bit by giving us
> back the more readable syntax of Objective C, in particular
> the method call syntax? It just made more sense to
> format a method call like Smalltalk.
> ___
> 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] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Sun Jul 10 2016, Jasdev Singh  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!
> 
> Hi Jasdev,
> 
> I wanted this once, before Swift 1 was released.  Its lack was easy to
> work around and I have never wanted it since, so... I'm afraid I don't
> think it is worth complicating the language for.  Your proposal shows
> how the feature *can be used*, but doesn't make a compelling case that it
> *will be very useful*.  That's what would be needed to convince me.

Have you looked into the design patterns it opens the door to, or how it is 
used in languages where it is present? IME it has to do with higher degrees of 
abstractions or more dynamic behaviors. Granted it is also not the only way to 
achieve that. TypeScript might interest you if you have not yet looked into it 
closely.

> 
> HTH,
> 
> -- 
> Dave
> 
> ___
> 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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 9:43 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
>> On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner  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?
> 
> +1. As a big proponent of API reviews for code that's going to end up being 
> used by others, I think sealed-by-default forces authors to think about how 
> their code might end up being used by others more so than more-permissive 
> alternatives

Believing that joe lambda devs might think about their code more because the 
compiler is going to prevent certain obscure behavior from happening seems IMHO 
like a blattant negation of what history tells us about human nature. Given 2 
choices, most of us will choose the one involving the least amount of thinking 
or work; and given 2 choices with different amount of responsibilities, most of 
use will choose the least amount of perceived individual responsibility. 
Psychology 101, demonstrated in many experimentations.

Doing it because the core team wants to do it has the merrit of recognizing 
that in the end, they hold the keyboard and should be free to write whatever 
they fancy, regardless of where the choir sings. Simple and clear.
Design by consensus is the worst form of design, and the Linux kernel would 
never have made it to where it is today if Linus had not ignored what he had to 
when he had to. Happens what must happen.. and there should be no need for the 
half baked logic that has sometimes been invoked.

> . Seeing a keyword that marks a class as unsealed is a good opportunity to 
> start a conversation in a code review.

I have honestly never seen ios devs doing that, including in large corps. Most 
devs I met were lone guys or small shops working on several things in parallel, 
with no code review and much less discussions about software design. 

> Given that Swift tries to encourage the use of value types over reference 
> types in many places, which can't be subclassed anyway, I don't think this 
> change should be a significant burden. I'm in the process of implementing a 
> fairly large library that's about 95% value types and 5% reference types. The 
> reference types are more of an implementation detail than a hierarchy of 
> types, so I would have them be final anyway. This is completely anecdotal, of 
> course, but it's a testament IMO to how differently Swift has me thinking 
> about the way I structure my APIs, and subclassing has been mostly replaced 
> by protocol extensions and composition.
> 
> I'm not compelled by the arguments that we need subclassing to fix bad APIs, 
> because that's absolutely not what subclassing is intended for. It's a hack, 
> and it's not a cure-all—it relies on being able to override the correct 
> methods and inject custom behavior in the first place. The argument shouldn't 
> be "we need open subclassing or we can't fix broken APIs"; that's a false 
> choice. It should be "we need *something* to fix broken APIs", and that 
> "something" should be proposed and the need for it should be argued in its 
> own right. The ability to fix a sealed broken API does have value, but it is 
> inherently unsafe because you might be making assumptions about 
> pre/post-conditions that the original class author didn't think about, and 
> those assumptions could become invalid in the future (or might rely on 
> internal implementation details that you cannot predict). Rather than abusing 
> a construct that is not suited for that purpose, those arguing for the need 
> for that functionality should propose something more appropriate. This would 
> be a win-win; we'd have a clean way of expressing API boundaries, and an 
> unsafe-but-acknowledged-as-such way of hooking into APIs if a trap door is 
> needed. (Of course, with Swift at such a young age, it's hard to know what 
> the needs for that are until we have some more mature libraries to present as 
> use cases.)
> 
>  
>> * Is the problem being addressed significant enough to warrant a 
>> change to Swift?
> 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 12:53 PM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> You do realize that then itunes store used to (i don't know hese days) for 
>> many years run on java, despite objc being such a more advanced environment. 
>> ;-)
> well, from my experience, app developers are running circles around the 
> itunes store all the time ;-)

Better yet... I once had lunch with the now defunct java team and the guy who 
did the java rewrite of webobjects... can you guess from what language? or why 
they had to do it? 
Still running circles?
;-)
Cheers & thank u for the smiles...


___
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 11, 2016, at 9:39 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> With the existence of Swift on the server, dynamically linked, independently 
>> distributed frameworks will not be an Apple-only issue - this extends beyond 
>> Apple's OS X-based platforms towards how dynamic frameworks link against 
>> each other as if they are to be distributed separately.
>> 
>> It is short sighted to suggest that all Swift deployments will be under 
>> Apple's control.
> I'm really looking forward for server-side Swift — I'm planning for years to 
> extend my portfolio in that direction, and Swift could really push that 
> diversification.
> 
> But I had a concrete reason for interest in writing my own backend-code:
> Server-side was imho broken on large scale, and it still isn't fixed yet… I 
> can run circles around those poor Java-developers who have to fight crusted 
> structures and deal with sluggish tools like Maven and Tomcat (and Java ;-).*

You do realize that then itunes store used to (i don't know hese days) for many 
years run on java, despite objc being such a more advanced environment. ;-)


> It seems to me I'm not alone with my opinion, because there are already 
> alternatives on the rise:
> Look at Docker — it's a huge success, because it not only takes application 
> and libraries to build a robust unit; it even includes a whole OS!
> 
> On iOS, it already hurts when you have a bunch of Swift-Apps which all have 
> the stdlib bundled — but on the server, this doesn't matter, and I'm 
> convinced it would be a bad move to propagate shared frameworks.
> 
> - Tino
> 
> * of course, there are agile alternatives — but in my environment, most of 
> the big players wouldn't even consider something like Rails
> 
> ___
> 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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 11, 2016, at 5:00 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jul 10, 2016, at 9:53 PM, Paul Cantrell via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution 
>>>  wrote:
>>> 
>>> 2. The motivation seems to be that it will force better API design.
>> 
>> No, that wasn’t my motivation in giving it a +1. This seems 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.
> 
> +1.  This is exactly why sealed is the default that fits best with the rest 
> of the defaults in Swift.  They are permissive within a module and require 
> explicit choices where external contracts are involved.
> 
>> 
>> 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.”
> 
> Agree.  The best practice has been around for some time, although it sounds 
> like it is not yet widespread as it could be (especially in-depth knowledge 
> of the rationale behind it).  
> 
> What is relatively new is the opportunity to embrace it in the design of a 
> (sure to be) popular and widely used language that carries most of the 
> traditional OO facilities.  This is a great opportunity IMO.

I find surprising to that one would sign up for what basically amounts to 
'compiler take my freedom away as I do not feel I can bare the responsibility 
it places on me'. To me, Joshua Bloch's message was never as an appeal to the 
javac teams to suppress freedom, but to developers to become cognizant of its 
consequences and strive to write better code. But it seems to be a human trait 
throughout history to want to relinquish our individual freedom for the comfort 
of someone else being responsible.

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

[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] [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] [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] 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] [Review] SE-0117: Default classes to be non-subclassable publicly

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 9, 2016, at 7:06 PM, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
> 
> 
>> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution 
>> <swift-evolution@swift.org> a écrit :
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>>> On Jul 9, 2016, at 8:39 AM, Andre <pyunp...@me.com> wrote:
>>>> 
>>>> Personally, Im not against sealed by default, but I think there are cases 
>>>> where closed source libraries have certain cases where workarounds are 
>>>> necessary, and just sealing by default will prevent those cases. 
>>>> 
>>>> One could say, "well just use an open source one, or change vendors" but 
>>>> its not that easy in The Real World™ where we get certain SDKs shoved down 
>>>> our throats by the suits… and while that may be a separate issue to the 
>>>> one at hand, its still a problem that won’t resolve itself by simply 
>>>> locking down things…
>>>> 
>>>> In my own case, Ive fought with NSBrowser / NSTreeController in the past 
>>>> and the only way to resolve things was to subclass (and no, waiting 1 or 2 
>>>> years for a fix is not acceptable if you already have a product in the 
>>>> wild).
>>>> 
>>>> So I am reticent to support this proposal without an escape hatch for 
>>>> those cases…
>>> 
>>> Are you concerned about closed-source vendor frameworks beyond Apple’s?  
>>> Some things to consider:
>>> 
>>> 1. This proposal should not impact any existing libraries - nobody should 
>>> be shipping closed-source binary libraries written in Swift yet.
>>> 
>>> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
>>> come.  If / when they are replaced with Swift frameworks the default will 
>>> have little (if any) impact on the public API contract.  It is reasonable 
>>> to expect that Apple will review the public contracts carefully and add any 
>>> annotations necessary to achieve the desired semantics.
>>> 
>>> 3. In the future, if you depend on any 3rd party closed-source libraries 
>>> written in Swift you will be able to ship an update to your app that 
>>> contains an updated / fixed version of the library independent of the user 
>>> upgrading their OS.
>>> 
>>> 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.  
>>> 
>>> There is no doubt that adopting sealed by default will place some pressure 
>>> on the Swift ecosystem.  As others have noted, this pressure already exists 
>>> in the form of value types, protocol-oriented designs, etc - the current 
>>> proposal is a relatively modest increase in that pressure.   I believe the 
>>> pressure will have a very positive impact over time (the eventual outcome 
>>> remains to be seen of course).  
>>> 
>>> Swift library vendors will need to choose between opening their source, 
>>> providing responsive support and bug fixes, explicitly providing the escape 
>>> hatch you mention (by designing with open types) or getting a bad 
>>> reputation among users.
>> 
>> There are IMO no advantages to sealing by default. If there were, I cannot 
>> imagine how they can have so consistently eluded the designers and 
>> maintainers of so many great OOD languages in the last 30 years. Does it 
>> mean it is just a matter of time for the core team to take it the c++ 
>> standardization committee to make sure C++ gets enhanced the same way?
> 
> You can’t compare Swift to C++ here. C++ uses « final » method and static 
> dispatch by default, so subclassing does not imply the same fragility than 
> with a fully dynamic language.

... and whole module optimization does final inferrance on anything internal... 
so how much more training wheels do we need to write decent code?  After 30 
years of Objc's msg dispatching being touted as not a performance problem, all 
we hear for the last couple WWDC (did you pay attention to the 'they are 
getting it' during one of the session) is how much every single dynamic 
dispa

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jul 9, 2016, at 8:39 AM, Andre  wrote:
>> 
>> Personally, Im not against sealed by default, but I think there are cases 
>> where closed source libraries have certain cases where workarounds are 
>> necessary, and just sealing by default will prevent those cases. 
>> 
>> One could say, "well just use an open source one, or change vendors" but its 
>> not that easy in The Real World™ where we get certain SDKs shoved down our 
>> throats by the suits… and while that may be a separate issue to the one at 
>> hand, its still a problem that won’t resolve itself by simply locking down 
>> things…
>> 
>> In my own case, Ive fought with NSBrowser / NSTreeController in the past and 
>> the only way to resolve things was to subclass (and no, waiting 1 or 2 years 
>> for a fix is not acceptable if you already have a product in the wild).
>> 
>> So I am reticent to support this proposal without an escape hatch for those 
>> cases…
> 
> Are you concerned about closed-source vendor frameworks beyond Apple’s?  Some 
> things to consider:
> 
> 1. This proposal should not impact any existing libraries - nobody should be 
> shipping closed-source binary libraries written in Swift yet.
> 
> 2. Apple’s frameworks will probably remain in Objective-C for some time to 
> come.  If / when they are replaced with Swift frameworks the default will 
> have little (if any) impact on the public API contract.  It is reasonable to 
> expect that Apple will review the public contracts carefully and add any 
> annotations necessary to achieve the desired semantics.
> 
> 3. In the future, if you depend on any 3rd party closed-source libraries 
> written in Swift you will be able to ship an update to your app that contains 
> an updated / fixed version of the library independent of the user upgrading 
> their OS.
> 
> 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.  
> 
> There is no doubt that adopting sealed by default will place some pressure on 
> the Swift ecosystem.  As others have noted, this pressure already exists in 
> the form of value types, protocol-oriented designs, etc - the current 
> proposal is a relatively modest increase in that pressure.   I believe the 
> pressure will have a very positive impact over time (the eventual outcome 
> remains to be seen of course).  
> 
> Swift library vendors will need to choose between opening their source, 
> providing responsive support and bug fixes, explicitly providing the escape 
> hatch you mention (by designing with open types) or getting a bad reputation 
> among users.

There are IMO no advantages to sealing by default. If there were, I cannot 
imagine how they can have so consistently eluded the designers and maintainers 
of so many great OOD languages in the last 30 years. Does it mean it is just a 
matter of time for the core team to take it the c++ standardization committee 
to make sure C++ gets enhanced the same way?

> 
> -Matthew
> 
>> 
>> Andre
>> 
>>> 2016/07/09 22:11、Shawn Erickson  のメール：
>>> 
>>> What I don't get in the arguments against this capability is the fact that 
>>> many constructs in Swift can't be subclassed. Are we going to prevent 
>>> library developers from presenting those in the public API? Your ability to 
>>> subclass things when not supported by the library developer is already 
>>> going to be greatly reduced. Additionally you are going to miss potentially 
>>> helpful optimization in side the model if the library developer can't 
>>> prevent extras subclassing.
>>> 
>>> It seems perfectly reasonable to allow a lot of freedoms for a library 
>>> developer when designing their code on their side of the library API and 
>>> not force them to expose unwanted API just because of internal design 
>>> desires. 
>>> 
>>> (I have myself have already struggled with having to leak what I consider 
>>> internal details outside of modules we have developed internally, likely 
>>> need to get around to outlining the additional issues I see)
>>> 
>>> In the end if the library isn't good and you don't like the API find one 
>>> that works the way you need (or make one). I expect a fairly rich 
>>> environment of libraries that will sort itself out over time.
>>> 
>>> -Shawn
 On Sat, Jul 9, 2016 at 8:43 AM Andre via swift-evolution 
  wrote:
 Hi,
 
 > However, you *do not* want any new subclasses added as you know that is 
 > not likely to end well.
 Im curious, what kind of real-world scenario would "not end well" cover?
 
 I’m genuinely curious, since Im still 

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

[L. Mihalkovic via swift-evolution]

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?


> 
> 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.
> 
> If ModelBase were public-but-not-subclassable, however, the code is perfectly 
> fine. The initializer and the helper type don’t need to be public, and 
> clients of the library see only what they need.
> 
> This is just one use case. I don’t want to say it’s a general model for 
> everyone’s code. However, it does point to a desire for 
> public-and-not-subclassable classes; any other solution would either require 
> the library author making more things public, or the compiler making it 
> possible to accidentally call an unimplemented initializer.
> 
> I’ll send a separate message with my thoughts as the primary author of the 
> Library Evolution model, to keep those discussions distinct. That one will 
> have a bit more ideology in it. :-)
> 
> Jordan
> 
> P.S. “Why not use protocols?” When a protocol has an initializer requirement, 
> it still forces all subclasses of a conforming class to provide an 
> implementation, i.e. the conforming class’s initializer still needs to be 
> declared ‘required’. That means it’s subject to the same restriction: a 
> required initializer must have as much access as the containing class.
> ___
> 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 7, 2016, at 6:23 PM, Leonardo Pessoa via swift-evolution 
>  wrote:
> 
> Jean, IMO marking every class as subclassable means the creator does
> not care for you to design and develop a great library because s/he is
> not caring for the library at all.

That is a grotesque depiction.

> I right now have to go through the
> burdensome activity of marking too many classes/methods as final to
> prevent misuse of my libraries and find good design workarounds when I
> need to subclass internally what I don't want you to subclass.

If one does not have the patience to review one's own work to increase its 
quality, and would instead prefer to hand off the responsibility of finishing 
writing it to the compiler (i.e. making the compiler lock things down to avoid 
having to type "final"), perhaps a happier solution for everyone might be 
easier to keep this work private? 
I noticed in recent years that the quality of some open source code has gone 
down, seemingly under the social pressure of having to be "one of the 
kool-ones" with code hanging in the breeze on github. Personally I don't mind 
if less code makes its way to github because it is more difficult to finish it 
properly.


> IMO the usage of a library is to be crafted/planned/designed by their
> developers not their users. Mine is the opinion of a library-maker,
> yours of the user of poorly designed/developed libraries. By pushing
> this proposal, developer of such libraries will have much burden to
> make/keep a poor library or will have to work on better
> design/implementation for it to suit its purpose.
> 
> L
> 
> On 7 July 2016 at 13:08, Jean-Daniel Dupas via swift-evolution
>  wrote:
>> * What is your evaluation of the proposal?
>> 
>> Strong -1 too.
>> 
>> I can’t count the number of times it save my hours tone able to override
>> arbitrary classes and methods.
>> 
>> Sometimes to simply add log point to understand how the API work. Other
>> times to workaround bugs in the library. Or even to extends the library in a
>> way that the author did not intent in the first place, but that was
>> perfectly supported anyway.
>> 
>> I already see how libraries author will react to that new default. They will
>> either don’t care and mark all classes as subclassable, or find to
>> burdensome to get subclassability right and prohibit subclassing all
>> classes.
>> 
>> 
>> Le 7 juil. 2016 à 02:27, Jonathan Hull via swift-evolution
>>  a écrit :
>> 
>> * What is your evaluation of the proposal?
>> 
>> A **strong** -1
>> 
>> First, I have often found that you can’t always predict the way which
>> something will need to be extended.  You think you know, but are then
>> surprised by creative uses.  My favorite features of Swift/Cocoa involve
>> retroactive modeling.
>> 
>> Second, I don’t think this proposal will achieve its stated objective of
>> forcing people to think about subclassing more.  It will just add confusing
>> boilerplate.
>> 
>> Things like Swift optionals work well because they make the (often
>> forgotten) choices explicit in the context that they are used.  In the world
>> of Human Factors, we call it a forcing function.  This proposal has the
>> inverse structure, and will be ineffective, because the “forcing” part of it
>> shows up in a different context (i.e. trying to use a framework) than the
>> decision is being made in (writing the framework).  This type of thinking
>> leads to things like Java and the DMV.
>> 
>> As Tino said:
>> 
>> No matter what the defaults are, good libraries are hard to build, so I
>> predict this proposal would not only fail in increasing framework quality,
>> but also will make it much harder for users of those frameworks to work
>> around their flaws, which are just a natural part of every software.
>> 
>> I think he is right on here.  Those who were prone to be thoughtful about
>> their design would have been anyway.  Those who are not thoughtful about
>> their design will just leave these annotations off… leaving us with no
>> recourse to extend/modify classes.  When people complain, they will add the
>> annotations without actually thinking about the meaning (i.e. stack overflow
>> / the fixit tells me I need to add this word to make the compiler happy).
>> All this does is put framework users at the mercy of the framework writers.
>> 
>> 
>> Finally, this proposal is missing important aspects of the problem space.
>> If we truly want to solve the issue of subclassing, we need to consider all
>> of the common issues which arise.  Looking at the cocoa documentation you
>> will see several types of annotations:
>> 1) This method MUST be overridden
>> 2) This method should NOT be overridden
>> 3) This method MUST be called
>> 3) This method should NOT be called except by subclasses
>> 4) This method should NOT be called except by a method override calling
>> super
>> 5) This method MUST call 

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

[L. Mihalkovic via swift-evolution]

It really looks like the process is showing its limits... with so many people, 
some with knowledge of compiler imposed limitations, most with a laundry list 
of their favorite features from other languages, and even a few aspiring at 
finally having anti-gravity boots into the compiler, it seems something might 
have to change to keep the debate while allowing more focus than has sometimes 
happened around hot topics. 
Regards
(From mobile)

> On Jul 7, 2016, at 9:02 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Jul 7, 2016 at 11:28 AM, Dmitri Gribenko via swift-evolution 
>>  wrote:
>> On Thu, Jul 7, 2016 at 9:27 AM, John McCall  wrote:
>> > On Jul 7, 2016, at 9:23 AM, Dmitri Gribenko via swift-evolution
>> >  wrote:
>> >> Proposal link:
>> >>
>> >>
>> >> https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>> >
>> > Dave, Max and I discussed SE-0077 and reviewed the names of precedence
>> > groups.
>> > Here's our recommendation.
>> >
>> > In general, we think some names don't read well and have some ambiguities,
>> > for
>> > example, "LogicalAndPrecedence" (looks like a conjunction),
>> > "AdditivePrecedence" ("additive" is an adjective that modifies
>> > "precedence"),
>> > "RangePrecedence" ("range" is not an adjective, stands out).
>> >
>> > We think that two directions would be fruitful:
>> >
>> > 1.  If the names of precedence groups will be in the same namespace as
>> > types,
>> > then we recommend pushing the names of precedence groups into a
>> > "namespace",
>> > for example "Precedence.Assignment".
>> >
>> >
>> > We don't have any language features that would allow this.
>> 
>> 'precedencegroup' that is being proposed is a new language feature, we
>> can choose to use any syntax we like with it.
>> 
> 
> If you're going to design a new language feature to sink precedence groups 
> into a namespace of their own, you might as well sink them into an 
> unutterable namespace, effectively moving them out of the same namespace as 
> types altogether, no?
>  
>> Dmitri
>> 
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>> ___
>> 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] Removing Variadic Parameters.

[L. Mihalkovic via swift-evolution]

Even vb does that... If you ever want to write a compiler or anything that has 
to dynamically adjust its behavior (which i would expect most objc devs never 
do) then it might be useful to not cut all the claws of this tigger.
Regards
LM
(From mobile)

> On Jul 6, 2016, at 8:38 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> It's a late answer… but I wanted to be a good citizen and checked if the 
> topic has been discussed before; so, it seems that is not the case ;-)
> 
> In short, I agree:
> Variadic parameters are somewhat cool, and I think I was exited when I've 
> seen them in C the first time… but I afair, I never created a variadic 
> function in production code, and I think I just used them for the first time 
> in Swift (I checked wether print is variadic…)
> As of today, string interpolation has several advantages over old-style 
> string-formatting, and I can't remember any other method in one of the 
> established libraries that uses this feature:
> Explicitly creating an array is just two additional characters, which doesn't 
> matter in a long list (which imho shouldn't be crammed into the function call 
> anyways), and when there are only a few parameters, you can mimic variadics 
> with Optionals defaulted to nil — and who knows what the long-awaited 
> hygienic macros might do to the importance of variadic parameters.
> 
> Additionally, variadic parameters compete with trailing closures, which for 
> me would always win the struggle for the last parameter ;-)
> 
> As I said, I can't remember a single use case in Swift — and I already 
> utilized quite a lot of the "strange" techniques (currying, tuple splat, 
> complicated combinations of generics & protocols…).
> So for me, the answer to the question "would I add this feature to Swift if 
> it wasn't there?" is a clear no…
> 
> Tino
> ___
> 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] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

[L. Mihalkovic via swift-evolution]

It looks like there are 2 views being discussed

Import System : just masks the difference in platform specific names
Import Libc : a true attempt at a swift specific view of credible c runtime 
equivalent

The first one would be easy to do now and would alleviate all the mindless 
#if...#endif we have today.

Regards
LM
(From mobile)

> On Jul 6, 2016, at 1:13 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 5, 2016, at 2:59 PM, Brian Gesiak via swift-evolution 
>>  wrote:
>> 
>> Sorry to resurrect such an old thread! I understand getting this in Swift 
>> 3.0 might not be realistic anymore, but this is still something I’d love to 
>> see added to Swift. Could someone advise on whether it still makes sense to 
>> spend time on this proposal? Or is this part of Swift too solidified to 
>> change at this point?
>> 
> It is definitely beyond Swift 3.0, but I’d love to see this happen at some 
> point, we really need someone to drive the (surely to be contentious) design 
> process.
> 
> -Chris
> 
> 
>> How much would Libc include? The standard C library? POSIX?
>> 
>> Yes, I had originally anticipated this as including module C and module 
>> POSIX. I see that module CUUID was recently added as well, but I don’t think 
>> that should be included.
>> 
>> there are differences (minor, but still) between Glibc and Darwin. Those 
>> should be either unified (if possible) or re-arranged so that the unified 
>> library shares unified functionality and then each separate one can have its 
>> own set of caveats.
>> 
>> I don’t think the unified import C module should do anything besides obviate 
>> the need to write the following:
>> 
>> #if os(Linux) || os(FreeBSD)
>> import Glibc
>> #else
>> import Darwin
>> #endif
>> If people feel strongly about unifying the overlay, perhaps we should 
>> discuss that in future swift-evolution proposals.
>> 
>> Personally, I like “import C”, but at the end of the day I’m happy to call 
>> it whatever as long as it solves the problem.
>> 
>> I couldn’t have said it better myself!
>> 
>> /cc Saleem, since he may have Windows opinions.
>> 
>> - Brian Gesiak
>> 
>> 
>>> On Wed, Mar 9, 2016 at 6:35 AM, Honza Dvorsky  wrote:
>>> A huge +1 on the proposal, I even have a code snippet to import the 
>>> platform-appropriate C library. I try to write every new Swift library 
>>> cross-platform-by-default now and this would definitely remove some 
>>> friction. Not to mention it would future-proof many libraries which won't 
>>> need to be updated when a new Swift platform is added.
>>> 
>>> Personally, I like "import C", but at the end of the day I'm happy to call 
>>> it whatever as long as it solves the problem. I agree with Brian that with 
>>> Swift scaling up to 4 or so platforms soon-ish, it's preferable to not put 
>>> any extra burden on Swift users if there is an almost-uniform C API which 
>>> can be used everywhere.
>>> 
>>> On Wed, Mar 9, 2016 at 2:03 AM Jordan Rose via swift-evolution 
>>>  wrote:
 One of the reasons we haven't picked this particular name is if the C or 
 C++ committees ever adopted modules. Given that they just got punted from 
 C++17, though, maybe that shouldn't hold us back.
 
 Jordan
 
 
> On Mar 8, 2016, at 11:13, Brian Gesiak via swift-evolution 
>  wrote:
> 
> # Introduction
> 
> Currently, cross-platform Swift programs that rely on symbols defined in 
> libc (`fputs`, `stderr`, etc.) must all write the same five lines of 
> boilerplate code:
> 
> #if os(Linux) || os(FreeBSD)
> import Glibc
> #else
> import Darwin
> #endif
> 
> Instead, I propose the following, which will work on all platforms:
> 
> import Libc
> 
> # Motivation
> 
> Let's say we wanted to write a program that, on any platform, would print 
> "Hello world!" to stderr. We'd probably come up with this:
> 
> #if os(Linux) || os(FreeBSD)
> import Glibc
> #else
> import Darwin
> #endif
> 
> fputs("Hello world!", stderr)
> 
> The first five lines of this program are necessary to import the symbols 
> `fputs` and `stderr`. Five lines may not be much, but these come with 
> significant drawbacks:
> 
> - They must be written in each source file that relies on libc, which is 
> tedious.
> - It is subject to frequent change. As Swift is ported to more platforms, 
> that initial check must change to `#if os(Linux) || os(FreeBSD) || 
> os(Windows) || os(Android)`, and so on. End users of Swift may not be 
> actively involved in its development, and so may be surprised when the 
> latest release suddenly necessitates more `os()` conditions.
> - These combined force users to make a 

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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jul 6, 2016, at 8:28 PM, Ted F.A. van Gaalen via swift-evolution 
>  wrote:
> 
> Hi there
> 
> From the perspective from many active programmers
> that use Swift (not objective C anymore) I am  not
> very happy by having to change
> program source all the time:   
> 
> Therefore after Swift 3.0 is released I’d recommend kindly:
> 
> 
> Freeze Swift For Some Time! 
> Do Not Change AnyThing For At Least 2 Years.
> (Yes you’ve read that correctly: two years.)
> 
> Still there? OK, read on:
> 
> In the mean time, you’ll have the great opportunity
> to fine-tune compiler and run time systems, to eliminate
> the few bugs there and make it blazingly fast!
> 
> In two (or more) years,  there are enough Real Users (programmers) 
> that by then will have enough practical experience with Swift, which
> might play a more solid role in improving Swift, and of course,
> are extremely happy with Swift, and that it is not changed
> all the time, So that they can concentrate on writing cool,
> reliable and decent programs, instead of revising it all
> the time! 
> 
> After such time, and much more intensive and practical usage, 
> it becomes clear, what is good in Swift and what is not.  
> What happens now, for instance, is that some base their “statistics” of which 
> language elements etc. are frequently used or not, merely upon scanning 
> a codebase of the relatively few (compared with e.g. ObjC, Java or C#) 
> programmers
> that use Swift now
> 
> Imho, Swift has not yet been in use long enough. It needs a prolonged time 
> because now, most users have relatively little experience using Swift, 
> thus the way they program now is not really representative with what one 
> really can do
> with this powerful language, compared to experienced (years, not months) 
> programmers in other languages. 
> Still a lot has to be discovered, has to settle and form good mental pictures 
> in 
> programmer’s minds. It is all going a bit too fast, I think.
> 
> 
> Please (if you did’t already) realize that already many source
> code all over the world is written in Swift therefore it is very, very
> important that backwards compatibility should be preserved as much 
> as possible. because  backwards-breaking-changes are a disaster
> to companies/individuals that have already hundreds or thousands
> of programs written in Swift.

The fact that some people jumped early on a not yet finished language should 
not constitute a jail for everyone else. Swift3 is starting to make a lot more 
sense, but it is still IMHO far from polished. We will live with 3, but if i 
knew this was the end of the road, i'd immediately push every large corp 
project i know to c#/xamarin, or even phonegap/typescript.


> 
> For comparison, until recently I did also programming projects on IBM
> mainframes for banks, insurance companies etc. The systems they use consists
> (per company) of literally thousands of Cobol and/or PL/1 programs written
> in all the years from ca 1970 until now. Still, one can take a program written
> in 1970 which compiles and runs flawlessly without any modification!

I had an interesting conversation with the manager of the java group at apple 7 
years ago who equated this behavior with being attributes of a 'failed 
technology' (then equally applied to java and cobol).


> All is backward compatible. If you would break backward
> compatibility in this domain you would probably be kicked of the planet..
> 
> 
> But even if we remain in macOS or iOS development, a huge amount of source
> code has been written in Objective C. Everyone would scream hell if you took
> out or change language elements.. 
> So please don’t. (it’s unnecessary) 
> 
> 
> When Swift arrived, to me, it had already everything I need, not really 
> missing anything.
> Of course, a programming language -like all things in life- is never perfect.
> 
> To me it was also perfectly OK that Swift wasn’t open source, because those 
> that
> have made Swift did a very good job. So one could even start thinking, why
> open source Swift? Why not leave it to Apple? 
> But I guess I won’t make many friends asking this..
> And I also realize that many good ideas comes from open source.
> 
> 
> To me, Swift 2.2 and also 3.0  is fine. 
> so, after that:
> you don’t have to change a thing.
> it works and has everything I need
> and is fast and stable. 
> stop removing things.
> thanks.
> 
> 
> Kind Regards from beautiful Speyer.de in Germany
> 
> TedvG
> ___
> 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
LM
(From mobile)

> On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> If you have a ParentClass and a SubClass, and the ParentClass is sealed 
>> while the SubClass is subclassable. What happens? No matter how this 
>> question is answered, I don't like the answer. (compile error => bad. || 
>> make it as the user wishes => bad; what do we gain by letting ParentClass 
>> remain sealed? || make ParentClass implicitly subclassable too => bad.)
> I'm happy that there are not only supporters for this proposal, but imho the 
> example is no compelling argument:
> With no doubt, I'd expect I can subclass only SubClass — like I can't 
> instantiate an abstract class, which is just fine for its children.
> ParentClass might do some dangerous things that don't happen in SubClass, so 
> there might even be a use-case (but imho it would be better if I could mark 
> ParentClass as internal in this situation).
> 
> But imho there is another aspect I haven't read about yet:
> "final by default" would have had direct impact on any developer, while this 
> proposal merely changes things for those who create libraries…
> So, the question is: How will those be build?
> 
> If you live in a world of secrets and non-disclosure, I can understand that 
> sealed is desirable — but that's not the future I want to see, and github is 
> a good indication that others share this opinion.
> 
> If you share the sympathy for Open source, the two scenarios are as follows:
> We stick with "open by default"; users of libraries will use them in ways 
> that the creator hasn't thought of before, and bugs will show up.
> But: We know how to deal with bugs, that's our job! So in the best case, we 
> find the reason for the bad behavior, create a pull request, and everyone is 
> happy.
> 
> With "sealed by default", the situation changes:
> Users are protected from some simple bugs, but nonetheless, they'll encounter 
> situations where the library doesn't do exactly what they want.
> So, you take a look at the source, find the problem, and fix it.
> It's no bug at all, it's just a tiny degree of freedom that is missing 
> because it wasn't important to the author.
> You can create a pull request as well, but it doesn't offer a real 
> improvement to the author, who is already busy with dozens of similar 
> requests by other users -> you end up with a custom branch with all the 
> housekeeping associated with it.
> 
> So overall, I'm quite sure that the proposal won't improve software quality, 
> but rather degrade it.

:) 

> Tino
> ___
> 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
LM
(From mobile)

> On Jul 6, 2016, at 7:52 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution 
>>  wrote:
>> 
>> * What is your evaluation of the proposal?
>> 
>> -1 as is. I do not want to be constrained by authors of libraries or
>> frameworks into interacting with a system in only the ways they forsee.
>> By making the default be non-subclassable, if a designer does not put
>> thought into all the ways a class can be used then I as a consumer of
>> the library am penalized.
> 
> Out of curiosity, what is your feeling about “internal” as the default level 
> of access control?  It seems that following your concern to its logical 
> conclusion would lead to a design where all members of a public class would 
> be forced to be public.  After all, the author of a library or framework may 
> not forsee the need to interact with a member that they did not explicitly 
> mark public

Can't really help for feel like it is training wheels all around... or padlocks 
on every kitchen cupboards. What if this had been the philosophy from swift 
0.1, what would the ecosystem look like today? (genuine question to which I do 
not have the answer)

> -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 (initialize:with:)

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jul 3, 2016, at 10:18 AM, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>> On Jul 2, 2016, at 8:10 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> I have a pile of naming quibbles; rather than describe them all in prose 
>> (which turned into a mess), I've annotated parts of the "Full 
>> UnsafeRawPointer API" section in a gist: 
>> .
>> 
> 
> 
> Let's bikeshed this easy one now... I’m curious what others think:
> 
>   // In general, I think you "initialize to" a value, not 
>   // "initialize with" a value. "with" is needlessly vacuous.
>   // 
>   // func initialize(_: T.Type, with: T, count: Int = 1)
>   //   -> UnsafeMutablePointer
>   func initialize(_: T.Type, to: T, count: Int = 1)
> -> UnsafeMutablePointer
> 
> `initialize` was recently renamed to `initialized(with:)`.
> 
> commit d96b051d28b6042adcc8b8692a918abddf211aec
> Author: Dave Abrahams 
> Date:   Tue Feb 23 15:12:24 2016 -0800
> 
> stdlib: initializePointee(_) => initialize(with:)
> 
> Tacking "Pointee" on just for unary operations (and especially
> operations with an optional count) created inconsistency.
> 
> So Swift 3 users have already migrated to this “better” name.
> 
> I agree that initialize(to:) is consistent with the language we use for 
> assigning values. But grammatically, I think initialize(with:) also makes 
> perfect sense and is just as common.

+1

> 
> In general, if there’s controversy, I’ll stick with the existing conventions 
> because there’s already enough to debate in this proposal.
> 
> -Andy
> ___
> 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-0111: Remove type system significance of function argument labels

[L. Mihalkovic via swift-evolution]

An interesting take on arg label/name, granted this is including destructuring 
of obj literals (so one level down from the method sig, but which is not 
without analogy to what could be done to tuples with named fields). The main 
point of comparison is what the type of f1 and f2 are. 

This is in typescript, where the signatures ultimately have to translate down 
to javascript where everything maps to 
f(p,q,r,s,t) {
  var p1 = arguments.0; // is p or this
   ...
}
last week i was back to writing lots of ts 1.8 code and i find the type system 
incredibly precise and flexible (P|Q... yeah)

// Type of f1 is (arg?: { x?: number, y?: number }) => void 
function f1({ x = 0, y = 0 } = {}) { } 

// And can be called as: 
f1(); 
f1({}); 
f1({ x: 1 }); 
f1({ y: 1 }); 
f1({ x: 1, y: 1 }); 

// Type of f2 is (arg?: (x: number, y?: number) => void 
function f2({ x, y = 0 } = { x: 0 }) { } 
f2(); 
f2({}); // Error, x not optional 
f2({ x: 1 }); 
f2({ y: 1 });  // Error, x not optional 
f2({ x: 1, y: 1 });

Regards
(From mobile)

> On Jun 30, 2016, at 8:26 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0111: Remove type system significance of function argument 
> labels" begins now and runs through July 4. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.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

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

[L. Mihalkovic via swift-evolution]

Ever considered looking at how typescript handles argument names in object 
literal deconstruction?

Regards
(From mobile)

On Jul 3, 2016, at 10:36 PM, Pyry Jahkola via swift-evolution 
 wrote:

>> On 30 Jun 2016, Chris Lattner wrote:
>> 
>> The review of "SE-0111: Remove type system significance of function argument 
>> labels" begins now and runs through July 4. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>> 
>> What is your evaluation of the proposal?
> 
> +1. With the way the community has settled using argument labels, it seems 
> clear to me that argument labels are part of a function's name and should not 
> affect its type.
> 
> What we currently have technically works because the compiler is quite 
> lenient in type conversions between different argument labels. But since 
> there are corner cases lurking where labels in the function type matter (as 
> demonstrated in the proposal), it's best we get rid of them entirely for 
> clarity. As it has been pointed out, the status quo also complicates the 
> overload resolution process and causes confusing error messages when the 
> compiler can't tell if your argument labels are wrong or argument types. 
> We're better without that complexity.
> 
> Further, I think removing this oddity could make function application with 
> tuples feasible again (a.k.a the simple form of "tuple splatting" with all 
> arguments in the tuple) by requiring to fully name the function before 
> passing the arguments tuple:
> 
> func doSomething(x: Int, y: Int) -> Bool { return true }
> func doSomething(any: Any) -> Bool { return false } // This can't 
> possibly be considered below.
> 
> let args = (1, 2)
> let named = (x: 1, y: 2)
> let f = doSomething(x:y:)
> f(args) // Unambiguous call, if the syntax is made legal 
> (again).
> doSomething(x:y:)(args) // So is this.
> doSomething(args)   // This would still be an error as per SE-0029.
> let tuples = [(1, 2), (3, 4), (5, 6)]
> print(tuples.map(f)) // This would be allowed. (Confusingly it already 
> works despite SE-0029!)
> 
> In particular, you couldn't apply a `func` function with a tuple (which was 
> what SE-0029 removed) but you could apply a qualified function reference 
> (SE-0021) as well as a function value (i.e. a named closure) with a tuple, 
> because both of them have set in stone their argument list length before the 
> tuple application and thus suffer from none of the disadvantages listed in 
> the motivation for SE-0029. That would of course need a separate proposal and 
> can be delayed until Swift 3 has been released.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> Yes.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> I think so.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Well, we've had argument labels in Objective-C but since it's not a strongly 
> typed language I don't think it applies for comparison. However, I naturally 
> feel argument labels in Objective-C as well are part of the function's name 
> rather than its type.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> More than a quick reading. I've suggested a similar idea before but didn't 
> motivate it well enough to gain interest back then. Big thanks to Austin for 
> driving it forward this time!
> 
> — Pyry
> 
> PS. Can anybody explain why the last example in my code above turned out to 
> be allowed even though SE-0029 seems to prohibit it? Here's a more 
> comprehensive test which made me positively surprised that it still worked 
> after SE-0029:
> 
> let f: (Int, Int) -> Int = (+)
> let x = (1, 2)
> let x, y = (3, 4)
> f(1, 2) //=> 3
> // f((1, 2))  // Does not compile, as expected 
> (SE-0029).
> // f(x)   // Does not compile, as expected.
> [x, y].map(f) //=> [3, 7] // Surprisingly compiles, but why?
> let g: ((Int, Int)) -> Int = f// Huh? So `f` can coerce to a 
> `(tuple) -> Int`?
> g(x) //=> 3   // So this is what made `map` work 
> above.
> (f as ((Int, Int)) -> Int)(x) //=> 3  // This works too, didn't expect it 
> to.
> [x, y].map(+)  //=> [3, 7]// Finally, why is this allowed 
> despite SE-0029?
> 
> ___
> 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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

On Jun 30, 2016, at 9:12 AM, John McCall  wrote:

>> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic  
>> wrote:
>> 
>> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution 
>>  wrote:
>> 
 On Jun 29, 2016, at 12:05 PM, Michael Peternell  
 wrote:
 I'm still unhappy about this "sealed by default" proposal. That really 
 looks like premature optimization to me. Instead there should be some 
 `sealed` keyword. Maybe it should be called `applepublic` :-p Everyone 
 will understand!
 
 `sealed` classes should be a special optimization used by optimizing 
 developers who ask for it. Don't make it an unwanted and un-asked-for 
 default optimization. The people who care for optimization much will learn 
 about `sealed` and be able to apply the concept in both cases. The people 
 who don't care about performance will just be disappointed by the 
 "implicitly sealed" behavior. And with this proposal, when I read 
 `unsealed` I can never know: "did this developer intend me to be able to 
 subclass this class? or did he just not want to restrict me 
 unnecessarily?" The documenting aspect of `unsealed` is so small.
 
 And `sealed` is just an optimization; IMHO the magic of static dispatch 
 lies in final classes or final methods. Sealing everything by default just 
 marks many classes and methods as implicitly final (because it can be 
 proven that they are not subclassed). I just don't think that all these 
 theoretical performance improvements are really worth the trouble in 
 practice.
>>> 
>>> I'm confused about why you think this is so much of a problem.  Do you 
>>> really anticipate writing so many Swift libraries with public classes?
>> 
>> Look at some of the public libs on github for server side swift.. one 
>> recently claimed 50 modules and counting... I think swift is missing a level 
>> of containment below modules, and people are starting to make up for it by 
>> creating a flury of (1class+1protocol) modules, especially now that package 
>> manager makes it so trivial to create them. I think this is only the 
>> begining... and nodejs is there to show how insane it could become:  
>> remember the recent "trimleft" nightmare (1 module with 15 LOC including 
>> brackets used pervasively that suddenly disapears).
> 
> I'm not arguing that there aren't going to be a lot of libraries.  We're all 
> excited about the number of libraries.  Libraries are great.  

The issue is that according to this year's very interesting talk on perf is 
that an app's startup time can get thrown over the limit by having to perform 
too much relocation during dylib loading. I doubt too many will actually pay 
attention (i just started a nodejs app a couple days ago and before it did 
anything, bringing in angular and a few other dependencies downloaded 168M in 
over 60 modules)

> I'm trying to understand whether the objections here — which only matter on 
> library boundaries — are motivated by any concrete experience writing such 
> libraries in Swift.
> 
> Michael's argument was that sealed-by-default will be a major problem for 
> those libraries and their users.  Let's suppose that there's a library with a 
> public class, and it's sealed by default.  We can conclude that the author 
> has never once tried to subclass this class outside of their library, because 
> if they had, they would have gotten a compiler error.  Therefore, at best, if 
> I hack the library to allow subclasses, I'm going to be doing something that 
> has never once been tested and certainly was not considered when the class 
> was written.  It's pretty clear that this is not the developer's intent.

I think that you r considering an already sophisticated developer to whom you 
attribute the thought of 'whats it gonna be to use my code'. compared to the 
real life i know. That said I spent some time thinking about your arguments and 
I guess i can live with sealed (

> Likewise, it's not true that "the documenting aspect of `unsealed` is so 
> small".  Under sealed-by-default, the developer has to make a conscious, 
> deliberate step to allow subclasses outside of their library.  They clearly 
> do intend for you to be able to subclass this class.  It's actually the 
> reverse situation where the user doesn't know how to interpret the code,

I believe most devs are not able to accurately predict what their code does and 
will allow to do be done. Over the last 20 years i have usually seen the most 
creative solutions being found despite what the original library writers did, 
but it is just my personal exp. i would prefer a world without forking 
dependencies, but... 

But i think you best argument is that idiomatic swift should not rely on 
classes as much as other languages. So in the end, the applicability will 
become 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jul 1, 2016, at 6:43 PM, John McCall via swift-evolution 
 wrote:

>>> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon  
>>> wrote:
>>> That starts to look an awful lot like a fifth access level just for classes 
>>> (I know you're not proposing one, but it could start to look that way to a 
>>> user).
>> 
>> You know, it *could* be.
>> 
>> Suppose that, in `internal` scope, you can do all of these things:
>> 
>> * Subclass a class.
>> * Add a case to an enum in an extension.[1]
>> * Add a stored property to a struct in an extension.
>> * Conform to a protocol (as opposed to just using and constraining with the 
>> existing conformances).
>> * Override an individual initializer, property, subscript, or method in an 
>> extension or subclass.[2]
>> 
>> But `public` does not permit them. You can *use* something that is public, 
>> but you can't extend it. `open`, on the other hand, *does* allow you to 
>> extend them. It means that outside code has (about) as much freedom to 
>> extend the `open` item as code inside your module does.
>> 
>> This approach would allow us to make the "sealing" very tight—if you changed 
>> a class from `public` to `open`, all of its `public` members would still be 
>> sealed—without actually making that a heavy burden on programmers who want 
>> things unsealed.
> 
> Yes, this is the way I've been thinking about it.
> 
>> This also suggests that perhaps `final` is best thought of as foreclosing 
>> the things that `open` permits, either within a module or in future versions:
>> 
>> * A `final` class can never be subclassed.
>> * A `final` enum can never have cases added.
>> * A `final` struct can never have stored properties added.
>> * A `final` protocol...well, okay, that one's pretty useless. Maybe there 
>> just aren't `final` protocols.[3]
>> * A `final` property, subscript, or method can never be overridden.
>> 
>> A `final` thing would be fast both inside and outside the module, because it 
>> would have guarantees about its size/dynamic type/implementation; an `open` 
>> thing would be slow both inside and outside, because it would have no such 
>> guarantees; and a non-`final`, non-`open` thing would be slow externally but 
>> fast internally.
> 
> This is an interesting thought.  Its application to 'struct', though, seems a 
> bit strange, since 'final' on classes doesn't remove the ability for the 
> module to change the stored properties (and clearly we wouldn't want it to do 
> so).
> 
>> [1] There's another thread floating around where I've seen people suggest 
>> that enums could never be open because you couldn't unique integer raw 
>> values to each case. I think that's a rather narrow view of what an enum is 
>> for; many, perhaps most, enums don't need raw values, and even those that do 
>> could support string raw values with little danger.
> 
> If we know that an enum needs to be extensible, we can leave room in its 
> implementation for cases with arbitrary associated values.  This isn't a 
> problem.
> 
> Raw values are perhaps different.

This is a situation I often run into in jave where I would use an enum to 
create a finite set of constants to be passed (say action identifers). But then 
this makes it very difficult for external modules to extend the core set of 
actions locally. So i generally windup with an enum and an interface (the enum 
implements the interface).
Then local extensions are free to define their own local enums to cover only 
their local extensions to the original core set of actions. Then the public api 
definition constrains the action parameter to be enum In 
the end this is a pattern I've come to like because tracing usage of the 
interface I can find all subsequent entensions to the core set of actions. Each 
subsequent set of extensions is just that: its own closed enum showing that 
they all form a coherent namespace for that extension (being a different enum 
than my original set, they do not prevent me extending the core set without 
risking name collisions with their extensions). The only cost is the heavier 
api declation site signature that is wearing the double enum & interface 
constraint.
The point is that you can extend enums without have to open them, and the 
resulting pattern may be even better than if you open the enum. The only 
hickup. Swift does not let you express

protocol Command{}
func myCommand Handler{}


>> [2] You can't currently override a member in an extension, but I think that 
>> would be essential for initializing extension stored properties and 
>> especially for adding cases to enums (you'd want to override members to 
>> handle your cases).
> 
> Yes, I think allowing extensions to override members is an eventual goal.  It 
> needs runtime support, though, and some careful language design.
> 
>> [3] Or maybe a `final` protocol can't be conformed to directly, but only 
>> through a sub-protocol (which could only 

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

[L. Mihalkovic via swift-evolution]

This is IMHO a loophole in the type system today: '.Type' being a contextual 
keyword that is part of no protocol, there is no formal definition for what its 
return type and what can be done is purely driven by the compiler 
implementation. I used to have my oen bread of typeId until I ran into 
ObjectIdentifier. This part of te language could use some finishing touches.
Regards
(From mobile)

> On Jul 1, 2016, at 3:20 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Additive question:
> 
> Can a type instance of a type SomeType.self SomeType.Type be Hashable?
> I really would want to use these in dictionaries or sets :)
> 
> [Any.Type: ValueType]
> 
> Set // Union type universe
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] Union Type

[L. Mihalkovic via swift-evolution]

@core team: should the be added to the list of common rejections for now or 
does it stand a chance in the next 2 or 3 versions?

Regards
LM
(From mobile)

> On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution 
>  wrote:
> 
> https://github.com/frogcjn/swift-evolution/blob/master/proposals/-union-type.md
> 
> Hi,
> 
> I'm now officially proposal the union type feature for Swift. Please see:
> 
> 
> https://github.com/apple/swift/commit/eb7311de065df7ea332cdde8782cb44f9f4a5121
> Introduction
> 
> Add union type grammar, represents the type which is one of other types.
> 
> var stringOrURL: String | URL = "https://www.apple.com;
> 
> 
> I would be thankful if someone support this idea and give some advice. Thanks!
> 
> 
> --
> Jiannan
> 
> 
> ___
> 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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution 
 wrote:

>> On Jun 29, 2016, at 12:05 PM, Michael Peternell  
>> wrote:
>> I'm still unhappy about this "sealed by default" proposal. That really looks 
>> like premature optimization to me. Instead there should be some `sealed` 
>> keyword. Maybe it should be called `applepublic` :-p Everyone will 
>> understand!
>> 
>> `sealed` classes should be a special optimization used by optimizing 
>> developers who ask for it. Don't make it an unwanted and un-asked-for 
>> default optimization. The people who care for optimization much will learn 
>> about `sealed` and be able to apply the concept in both cases. The people 
>> who don't care about performance will just be disappointed by the 
>> "implicitly sealed" behavior. And with this proposal, when I read `unsealed` 
>> I can never know: "did this developer intend me to be able to subclass this 
>> class? or did he just not want to restrict me unnecessarily?" The 
>> documenting aspect of `unsealed` is so small.
>> 
>> And `sealed` is just an optimization; IMHO the magic of static dispatch lies 
>> in final classes or final methods. Sealing everything by default just marks 
>> many classes and methods as implicitly final (because it can be proven that 
>> they are not subclassed). I just don't think that all these theoretical 
>> performance improvements are really worth the trouble in practice.
> 
> I'm confused about why you think this is so much of a problem.  Do you really 
> anticipate writing so many Swift libraries with public classes?
> 

Look at some of the public libs on github for server side swift.. one recently 
claimed 50 modules and counting... I think swift is missing a level of 
containment below modules, and people are starting to make up for it by 
creating a flury of (1class+1protocol) modules, especially now that package 
manager makes it so trivial to create them. I think this is only the 
begining... and nodejs is there to show how insane it could become:  remember 
the recent "trimleft" nightmare (1 module with 15 LOC including brackets used 
pervasively that suddenly disapears).


> John.
> 
>> 
>> -Michael
>> 
>>> Am 29.06.2016 um 20:39 schrieb Vladimir.S via swift-evolution 
>>> :
>>> 
>>> How about `public(extensible)` ?
>>> 
>>> On 29.06.2016 21:32, John McCall via swift-evolution wrote:
> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution 
>  wrote:
> Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't 
> really make sense. `internal` declarations are always sealed.
 
 Right.
 
 If "sealed" is the default behavior for public classes and methods — and I 
 don't think the modifier is worth adding unless it's the default — then we 
 need a way of "unsealing" classes and methods that's fairly pithy.  I 
 don't think a parenthesized spelling is good enough for that.  And we 
 should try to make the positive form ("can be overridden") shorter than 
 the negative ("cannot be overridden"), because the latter will not usually 
 be written.
 
 To me, the ideal spelling would be usable in place of "public".  If it 
 does have to be stacked with "public", then I think it ought to be pretty 
 short.
 
 "communal"? :)
 
 "open" doesn't carry quite the right meaning, and it would need to be 
 paired with "public", I think.
 
 John.
 
 
> 
> -Michael
> 
>> Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution 
>> :
>> 
>> Do we really need a new keyword? Since we already have syntax like 
>> `internal(set)` couldn't we do `internal(unsealed)`, etc.
>> 
>>> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution 
>>>  wrote:
>>> On Jun 29, 2016, at 12:15 PM, Michael Peternell 
>>>  wrote:
>>> 
>>> 
 Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution 
 :
 
 +1 for the concept of a "sealed” class.
 -1 for making it default.
>>> 
>>> Aren't sealed classes already implemented? I think the keyword is 
>>> `final`..
>>> So there is nothing left to do :)
>> 
>> No, `final` doesn’t allow for any subclassing, but `sealed` allows for 
>> subclassing within your module (where you can presumably write more 
>> efficient code based on knowledge of each subclass).
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution 

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> How about `public(extensible)` ?
> 
> On 29.06.2016 21:32, John McCall via swift-evolution wrote:
>>> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution 
>>>  wrote:
>>> Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really 
>>> make sense. `internal` declarations are always sealed.
>> 
>> Right.
>> 
>> If "sealed" is the default behavior for public classes and methods — and I 
>> don't think the modifier is worth adding unless it's the default

What a jump... I am very curious about this rational that seems so obvious to 
you?

>> — then we need a way of "unsealing" classes and methods that's fairly pithy. 
>>  I don't think a parenthesized spelling is good enough for that.  And we 
>> should try to make the positive form ("can be overridden") shorter than the 
>> negative ("cannot be overridden"), because the latter will not usually be 
>> written.
>> 
>> To me, the ideal spelling would be usable in place of "public".  If it does 
>> have to be stacked with "public", then I think it ought to be pretty short.
>> 
>> "communal"? :)
>> 
>> "open" doesn't carry quite the right meaning, and it would need to be paired 
>> with "public", I think.
>> 
>> John.
>> 
>> 
>>> 
>>> -Michael
>>> 
 Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution 
 :
 
 Do we really need a new keyword? Since we already have syntax like 
 `internal(set)` couldn't we do `internal(unsealed)`, etc.
 
> On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution 
>  wrote:
> On Jun 29, 2016, at 12:15 PM, Michael Peternell 
>  wrote:
> 
> 
>> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution 
>> :
>> 
>> +1 for the concept of a "sealed” class.
>> -1 for making it default.
> 
> Aren't sealed classes already implemented? I think the keyword is 
> `final`..
> So there is nothing left to do :)
 
 No, `final` doesn’t allow for any subclassing, but `sealed` allows for 
 subclassing within your module (where you can presumably write more 
 efficient code based on knowledge of each subclass).
 
 - Dave Sweeris
 ___
 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
>> 
> ___
> 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] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic via swift-evolution]

Comparing with c++ is interesting... Do you remember that when u look at the 
implementation, the modifier is on every single method, so that when looking at 
a single page of code u do not have to go far to be reminded of the signature 
of what you are modifying... additionally, because the impl is separate, the 
code does not have to float 2 tabs away fromthe left margin (not to mention 
that in c++ we tend to favor 2 spaces indentations). Altogether the c++ has a 
more viable set of compromises than this proposal offers.
Regards
(From mobile)

> On Jun 29, 2016, at 11:41 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> Speaking of C++, is the “group” keyword even necessary? To borrow your own 
> example from earlier, it seems like we could just as easily say this:
> public struct A {
> public { // all public
> func member1() {}
> func member2() {}
> func member3() {}
> }
> public labelName {// all public, accessible under `foo.lableName`
> func member4() {}
> func member5() {}
> func member6() {}
> }
> }
> (which is not C++’s syntax, I know… the comment just got me thinking about it 
> is all)
> 
> - Dave Sweeris
> 
>> On Jun 29, 2016, at 1:03 PM, Adrian Zubarev via swift-evolution 
>>  wrote:
>> 
>> Looking at how c++ has a similar access modifier indent mechanism I’m still 
>> wondering if you’d argue about scrolling there.
>> 
>> with no assistance to find where it is
>> An assistant isn’t something the language solves for you. This is a 
>> different talk about the IDE. Grab some stdlib or foundation code and look 
>> at the filename and the code inside the file. The file might not contain 
>> only a single type equal to the filename. Also if there is another huge type 
>> present and you have a small display and currently looking at some specific 
>> member in the middle of that that type, which assistance have to find out 
>> the type of that member? Here we go again: you’re own assistant will your 
>> own negative argument ‘scrolling’.
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> ___
>> 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] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 8:39 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> How is this worse? Your argument about scrolling is just ridiculous.
> 

Look you may want to consider your language... did i call the proposal 
ridiculous? I could have ... The fact that you do not seem to understand or 
agree with something does not change its validity. I find the proposal highly 
impractical when considered at scale and truly hope it does not make it into 
the language.

> I can repeat myself but this time you could look a some current extension 
> without any conformances. If all members don’t override the default access 
> modifier you’ll end up in the same situation. Your argument is about the lack 
> of an assistant to see some information about a member, which is indeed not 
> present in the model of a group, but it also isn’t in protocols and in some 
> extensions.
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 29. Juni 2016 um 20:32:01, L. Mihalkovic (laurent.mihalko...@gmail.com) 
> schrieb:
> 
>> Is this argument a translation for "look, the problem already exists, so it 
>> should really not matter that we make it worse"? 
> 
> ___
> 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] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 8:16 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge 
> protocol that does not fit on your screen, which assistance do you have to 
> get its access modifier?
> 

Is this argument a translation for "look, the problem already exists, so it 
should really not matter that we make it worse"? 

> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 29. Juni 2016 um 20:03:31, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> Looking at how c++ has a similar access modifier indent mechanism I’m still 
>> wondering if you’d argue about scrolling there.
>> 
>> with no assistance to find where it is
>> An assistant isn’t something the language solves for you. This is a 
>> different talk about the IDE. Grab some stdlib or foundation code and look 
>> at the filename and the code inside the file. The file might not contain 
>> only a single type equal to the filename. Also if there is another huge type 
>> present and you have a small display and currently looking at some specific 
>> member in the middle of that that type, which assistance have to find out 
>> the type of that member? Here we go again: you’re own assistant will your 
>> own negative argument ‘scrolling’.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
> 
> ___
> 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] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 7:43 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Am I understanding your feedback right that you’re in favor of this:
> 
> public class func member1() {}
> public class func member2() {}
> public class func member3() {}
> public class func member4() {}
> public class func member5() {}
> Instead of:
> 
> public class group {
> 
> func member1() {}
> func member2() {}
> func member3() {}
> func member4() {}
> func member5() {}
> }
> And you’re argument is ‘scrolling back’?
> 
No sure i understand your point here. The problem i see with this proposal is 
that what may look quaint with empty methods in an email will turn into a 
practicality nightmare with real code. If I recall, there was even a past 
argument from a core team member (chris?) about something different but 
alluding to a very similar lack-of-practicality-at-scale.

> 
> Am 29. Juni 2016 um 19:35:35, L. Mihalkovic (laurent.mihalko...@gmail.com) 
> schrieb:
> 
>> -1 looks like a kludgy hack. 
>> It will force people to have to scroll back to the declaration of a group 
>> (with no assistance to find where it is) in order to ascertain the 
>> visibility of a given method, while pushing code further to the right for 
>> every single method. Couple that with the zealous following of the 80c rules 
>> and that makes for a less than stellar coding experience... all in the name 
>> of not have to type a modifier.
>> Regards
> 
> ___
> 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] [Post Swift 3] [Proposal] Introducing `group` mechanism

[L. Mihalkovic via swift-evolution]

-1 looks like a kludgy hack. 
It will force people to have to scroll back to the declaration of a group (with 
no assistance to find where it is) in order to ascertain the visibility of a 
given method, while pushing code further to the right for every single method. 
Couple that with the zealous following of the 80c rules and that makes for a 
less than stellar coding experience... all in the name of not have to type a 
modifier.
Regards
(From mobile)

> On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Dear Swift community, as most of you may know we’ve been discussing the 
> future of extintials and diverse design ideas. The result for Swift 3 is a 
> proposal which makes the first step by replacing procotol with a new 
> shorthand syntax A & B.
> 
> The reason I’m posting this proposal so early is to get some feedback about 
> this idea in general. If the feedback is positive, I also would like some of 
> you to consider the removal of the access modifier from extensions. By that I 
> don’t mean to remove it completely. My honest opinion is that extensions 
> should have exactly the same access control like classes, enums and structs.
> 
> One take the access control from protocols and mix it with the access control 
> of classes (etc.) and the result is the access control for extensions. I just 
> can’t agree with the fact of laziness of typing out access modifier on 
> extension members some of you might have.
> 
> The current access control on extensions disallow us to use access modifier 
> when we involve protocol conformances.
> 
> Default implementations have three ways of declaring public visibility:
> 
> extension SomeProtocol {
> public func someMember() {}
> }
>  
> public extension SomeProtocol {
> func someMember() {}
> }
>  
> public extension SomeProtocol {
> public func someMember() {}
> }
> If it was the access control mechanism for classes (etc.) there would be only 
> a single correct way to achieve this:
> 
> public class SomeClass {
> public func someMember() {}
> }
> Feel free to join the conversation about removing the current behavior from 
> extensions for Swift 3. Here is the >>link<< to the last post. (I still have 
> to rewrite a few things to reflect my thoughts from the conversation.)
> 
> I’d like to introduce a new scoped but typeless mechanism to Swift (which 
> might be added after Swift 3 drops). I gave it a clean name group to showcase 
> what it will be used for. You can read my formatted draft >>here<<.
> 
> These were the basic ideas I had. I’ve already seen a few threads where some 
> people were asking for a way organizing variables into groups by an access 
> modifier. So here it is, but a group can solve other problems too. We could 
> finally stop abusing enums and also create access labels for a clear and 
> swifty code design.
> 
> The idea of groups is based on the access control of protocols. It would be 
> great if this mechanism could have its own scope, which then could be used 
> almost anywhere.
> 
> Detailed design
> 
> A group is typeless, and should be used for organization purposes.
> 
> Organizing members by an access modifier.
> 
> Providing an access label to type members (CamelCase).
> 
> Providing namespacing for API design (UpperCamelCase).
> 
> public group Reference {
> /* implicitly public */ class String { ... }
> /* implicitly public */ class Char { ... }
> }
> Possible usage:
> 
> let instance = Reference.String()  
> A group can be used inside any scope or at file level.
> 
> A group has one or no label at all:
> 
> A group without a label has always an explicit access modifier:
> 
> public struct A {
>  
> public group {
> var a: Int { return self._a }
> var aTimesTen: Int { return self.a * 10 }
> }
>  
> internal group {
> var _a: Int = 10
> var _b: Int = 42
> }
> }
> A group with a label has an optional access modifier:
> 
> Labeled groups without an access modifier are automatically internal.
> Group members have the same access modifier as the group itself (like access 
> modifier on protocols).
> Nested groups inherit the access modifier from its root group.
> Labeled groups cannot be stored in any manner.
> public class UIScrollView : ... {
>  
> public group {
>  
> /* implicitly public */ group content {
> /* implicitly public */ var offset: CGPoint
> /* implicitly public */ var size: CGSize
> /* implicitly public */ var inset: UIEdgeInsets
> }
>  
> /* implicitly public */ var someCoolPublicInteger: Int
> }
> ...
> }
> Possible usage:
> 
> - scrollViewInstance.contentOffset
> + scrollViewInstance.content.offset
> It should be possible to create multiple groups with the same/different 
> access modfier and the same acess label:
> 
> public struct B {
>  
> 

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

[L. Mihalkovic via swift-evolution]

@brent: i noticed that you have the habit of redacting out the name of the 
people from your replies. Considering you seem to be the only one, and how much 
clarity it removes from the dialog, do you think you could perhaps reconsider?
Regards
LM
(From mobile)

On Jun 29, 2016, at 12:40 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> I was in the midst of writing a reply along the same lines, so I figured I'd 
>> add to David's reply here. There are two characteristics I would expect from 
>> a method named "prefix" or "suffix".
>> 
>> First, it should return a subsequence containing zero to count elements. (By 
>> contrast, something named "first" should return nil or one element, but 
>> certainly no more.)
>> 
>> Second, in the case of "prefix", the first element of the subsequence (if 
>> any) should be the first element of the sequence; in the case of "suffix", 
>> the last element of the subsequence (if any) should be the last element of 
>> the sequence.
> 
> I would phrase these things slightly differently. In my thinking, a method 
> with `prefix` or `suffix` in its name:
> 
>1. Operates on a subsequence at the beginning/end of the sequence,
> 
>2. Measured *relative* to the beginning/end.
> 
> An index-based operation doesn't fit this definition because an index is not 
> *relative* to anything—it's an *absolute* position within the sequence.
> 
> Put another way, in my view, "prefix" and "suffix" don't merely mean 
> "anchored at the beginning/end". A prefix or suffix is attached to a 
> "middle". There is no middle in the index-based operations.
> 
> It is, of course, very possible to use methods to express what the 
> index-based operations do:
> 
>friends.upTo(i)
>friends.through(i)
>friends.from(i)
> 
> But at this point, we've basically arrived at `friends[to: i]` etc.
> 
> -- 
> 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] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

On Jun 28, 2016, at 6:32 PM, John McCall  wrote:

>> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic  
>> wrote:
>> 
>> Question inline
>> Regards
>> LM
>> (From mobile)
>> On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution 
>>  wrote:
>> 
 On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution 
  wrote:
 I replaced `precedencegroup` with `precedence` and added `Precedence` 
 suffix to all precedence group names. See:
 
 https://github.com/Anton3/swift-evolution/blob/fix-operator-
 precedence/proposals/0077-operator-precedence.md
 
 My feelings:
 1. `precedencegroup` describes what it declares more precisely
 2. `precedence` is shorter (partially compensating for longer names)
 3. `precedence` can be correctly interpreted as "precedence level"
 4. `precedence` looks nicer overall
>>> 
>>> Keep in mind that this is a pretty marginal feature.  I'm not sure 
>>> "precedence" is a reasonable enough thing to take as a keyword for it.
>>> 
>>> John.
>> 
>> Would a meta-circular definition be possible (proposed a version using 
>> enums)? I remember a mail from chris about moving certain things currently 
>> backed into the compiler towards the stdlib, is this one a possible 
>> candidate...
> 
> This is already strongly library-determined.  The library defines what 
> operators exist and defines their precedence w.r.t. each other and a small 
> number of built-in operators.  Operator precedence has to be communicated to 
> the compiler somehow in order to parse code.  This proposal is just deciding 
> the syntax of that communication.
> 
> I see no reason to use a more conceptually complex approach when a simple 
> declaration will do.

Np... I thought that enums instead of keywords would also make them naturally 
discoverable when a reflection API gets created. Felt odd to see so many new 
language keywd assigned to a single feature. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 8:04 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> Hey, all. An engineer at Apple noticed the following behavior:
>> 
>> 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 2. @objc class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) 
>> runtime name
>> 3. @objc(Foo) class Foo: NSObject → exposed to Objective-C, unmangled 
>> runtime name
>> 
>> (and 4. @objc class Foo → illegal, classes must have ObjC heritage to be 
>> @objc.)
>> 
>> They specifically observed that (1) and (2) have the same behavior, and 
>> suggested that maybe (2) should be shorthand for (3).
>> 
>> Pros:
>> - There aren't two ways to spell (1).
>> - Removing the mangling (and module uniquing) from the runtime name is 
>> probably one of the most common uses of @objc on a class.
>> 
>> Cons:
>> - It's a source-breaking change, for all that the "@objc" in (2) is 
>> redundant.
>> - For protocols, (1) and (2) are not equivalent, because @objc isn't 
>> inherited there.
>> - Mangling is used to namespace class names at run time; if you drop that, 
>> the ObjC name should probably have a prefix. (This applies more to 
>> frameworks than apps, though.)
> 
> I’m -1 on this, because bare “@objc” in other contexts means “make sure this 
> is exposed to Objective-C, but I don’t want to be explicit about the name” 
> while “@objc(something)” means “make sure this is exposed to Objective-C, and 
> ‘something’ is the name”. 
> 

-1 
Please'o'please ... I find it useful for complexifying simple swift names into 
the kind that typically exists on the objc side.


>   - Doug
> 
> 
> ___
> 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] Setter methods for vars

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 29, 2016, at 1:11 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Really?? Or we just have #set and #get and no lenses, and it's done for Swift 
> 3?
> 
> I never heard of lenses (Google does not help here). Was this serious or were 
> you joking?

http://days2012.scala-lang.org/sites/days2012/files/morris_lenses.pdf

Not a joke at all. Read first sentence for brief definition.

> Unless you can explain why #set and #get without lenses would be bad... or 
> maybe #set and #get *are* lenses, in which case I'm not sure what you were 
> trying to say. Reflexion -> Reflection?
> 
> -Michael
> 
>> Am 29.06.2016 um 00:55 schrieb David Hart via swift-evolution 
>> :
>> 
>> This looks like lenses. I think we need to wait until after Swift 3 to 
>> discuss it, and come up with a bigger design that ties to reflexion.
>> 
>>> On 28 Jun 2016, at 22:04, Michael Peternell via swift-evolution 
>>>  wrote:
>>> 
>>> So you're proposing that `#set(aVariableName)` should translate to 
>>> `{aVariableName=$0}`, right? Where aVariableName can be any valid lvalue 
>>> like `self.users` or `users` or `vc.viewControllers`..
>>> 
>>> I think this would be a good extension to Swift. (`users.set` does not work 
>>> BTW, because maybe the `users` object has a `set` property.. maybe I wanted 
>>> to refer to the `set` property which also happens to refer to a closure 
>>> value.)
>>> 
>>> `#set(aVariableName)` also feels consistent with the 
>>> `#keyPath(aVariableName)` property and falls into a similar category. Maybe 
>>> `#setter(aVariableName)` would be even more clear? Furthermore, I want to 
>>> additionally propose to introduce `#get(aVariableName)` (or 
>>> `#getter(aVariableName)`) too.
>>> 
>>> -Michael
>>> 
 Am 28.06.2016 um 20:18 schrieb Austin Feight via swift-evolution 
 :
 
 Proposal:
 
 I propose adding setter methods to vars, which could look something like 
 this: `ApiClient().fetchUsers().then(#set(users))`
 
 Initially I thought it should work like this: 
 `ApiClient().fetchUsers().then(users.set)`
 but to accomplish a line of code that flows grammatically, I believe 
 putting "set" where it would naturally fall if the code was being read as 
 a sentence is more Swifty.
 
 Rationale:
 
 The following code makes me smile:
 
 ApiClient().fetchUsers().then(displayUsers)
 
 It exemplifies the beauty of Swift. First-class functions make this line 
 of code read very well. Consider some alternatives:
 
 1. ApiClient().fetchUsers().then { displayUsers($0) }
 2. ApiClient().fetchUsers().then { users in displayUsers(users) }
 3. ApiClient().fetchUsers().then { (users: [User]) in displayUsers(users) }
 
 Using the lessons learned from Swift API Design Guidelines (WWDC 2016 
 Session 403) having an emphasis on clarity, my analysis of the 
 alternatives is:
 
 1. $0 adds no additional information as to the type or explanation of what 
 the argument is, thus adding nothing to the line of code for clarity, and 
 therefore should be omitted
 2. adding "users" also adds nothing to the clarity of the code. The 
 function, properly, contains the information necessary to reason about the 
 argument it takes and what it does, and therefore adding "users" is 
 redundant
 3. Not only is "users" redundant, but also is the explicit type label. The 
 `displayUsers` method will only accept one type of argument, so we're 
 duplicating information that the compiler (and autocomplete) already gives 
 us
 
 With this I conclude that `ApiClient().fetchUsers().then(displayUsers)` is 
 the Swiftiest option.
 I want to extend this same logic to when I find myself writing code like 
 this:
 
 ApiClient().fetchUsers().then { users in
 self.users = users
 }
 
 or alternatively, because "users" is likely redundant information again,
 
 ApiClient().fetchUsers().then { self.users = $0 }
 
 Personally I steer clear of `$0` as much as possible, because I very 
 rarely feel that it provides the information necessary for code clarity. 
 But beyond that, this code no longer reads as nicely as the code we had 
 before. 
 
 Whereas `ApiClient().fetchUsers().then(displayUsers)` flows nicely as a 
 sentence and reads grammatically, `ApiClient().fetchUsers().then { 
 self.users = $0 }` no longer does.
 
 I think this feature could have a simple implementation where the compiler 
 replaces `#set(X)` with `{ X = $0 }`, and I believe it would go a long way 
 with respect to code clarity, especially when X is something longer like 
 `self.view.bounds.origin.x`
 
 
 Looking forward to hearing thoughts from the community,
 Austin 

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Question inline
Regards
LM
(From mobile)
On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution 
 wrote:

>> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution 
>>  wrote:
>> I replaced `precedencegroup` with `precedence` and added `Precedence` 
>> suffix to all precedence group names. See:
>> 
>> https://github.com/Anton3/swift-evolution/blob/fix-operator-
>> precedence/proposals/0077-operator-precedence.md
>> 
>> My feelings:
>> 1. `precedencegroup` describes what it declares more precisely
>> 2. `precedence` is shorter (partially compensating for longer names)
>> 3. `precedence` can be correctly interpreted as "precedence level"
>> 4. `precedence` looks nicer overall
> 
> Keep in mind that this is a pretty marginal feature.  I'm not sure 
> "precedence" is a reasonable enough thing to take as a keyword for it.
> 
> John.

Would a meta-circular definition be possible (proposed a version using enums)? 
I remember a mail from chris about moving certain things currently backed into 
the compiler towards the stdlib, is this one a possible candidate... 

> 
>> 
>> 5. `Precedence` suffix is bulky. One must specify it in operator 
>> declarations and in all relationships
>> 6. All groups ending with adjectives may unambiguously drop the suffix
>> 7. Number of such groups is small. New groups will tend to be named after 
>> corresponding operators, and they will be noun-based
>> 
>> Questions:
>> 1. Where else can we drop -Precedence?
>> 2. Can we make more names end with adjectives?
>> 
>> ___
>> 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] [Proposal] Sealed classes by default

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 5:24 PM, Matthew Johnson via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>> On Jun 28, 2016, at 10:17 AM, Mark Lacey via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>>> On Jun 28, 2016, at 7:55 AM, Sean Heber <s...@fifthace.com> wrote:
>>>> 
>>>>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> 
>>>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> -1 for the fact that if all devs can write working code, fewer can do it 
>>>>> in a clear structured fashion that is well designed for extensibility.
>>>> 
>>>> This sounds more like an argument for having sealed classes than not. As 
>>>> the proposal points out in the motivation, if the base class is not 
>>>> designed with subclassing in mind then overriding methods can result in 
>>>> unintended behavior (e.g. crashing, or other bugs).
>>> 
>>> But I think the counter argument is, what if you need to fix or workaround 
>>> unintended behavior of the class you’re trying to use?
>> 
>> Sure, I understand that, and I don’t mean to trivialize that concern. I’m 
>> just pointing out that “code…that is [not] well designed for extensibility”, 
>> might not  work very well if you start using extension points that weren’t 
>> well thought through.
>> 
>> If you are designing for extensibility you’ll be carefully thinking about 
>> what should and should not be final both within and outside of your module.

We all think carefully about what we do... it just does not mean the same in 
regards to the outcome. It seems it is only in the software industry that we 
all think of ourselves as michelangelos or rubens.. unfortunately it takes a 
lot of errors to become humble about it.

>> Not doing so can result in bugs. This proposal introduces the ability to 
>> allow extension within the module but restrict it outside the module, and 
>> defaults to not allowing extension beyond the module.
>> 
>> You can argue both ways which default would be better, and I suspect people 
>> who mostly write libraries might opt for sealed-by-default, and people who 
>> mostly consume libraries might opt for open-by-default. My point is that 
>> open-by-default isn’t “better” because it allows you to potentially work 
>> around a problem in a base class, because by working around that problem by 
>> overriding a method that wasn’t designed to be overridden you don’t know how 
>> many other new problems you might be introducing (now or in the future if 
>> the implementation of the base class changes).
> 
> I think a good argument for sealed by default is that if we introduce 
> `sealed` responsible library authors will already be marking all classes not 
> intended for external subclassing as either `sealed` or `final` anyway.   The 
> intended (and hopefully actual) public  API will be identical regardless of 
> the default.  Making it the default avoids a lot of boilerplate keywords and 
> makes ensure the API contract is stated more explicitly.
> 
> The only case where the default should make a difference is when a library is 
> written without consideration of subclasses.  As you point out, in that case 
> it is a really bad idea to attempt to work around a bug with a subclass.
> 
>> 
>> Mark
>> 
>> ___
>> 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] [Proposal] Sealed classes by default

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 4:59 PM, Charlie Monroe via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>>> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 
>>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> -1 for the fact that if all devs can write working code, fewer can do it 
>>>> in a clear structured fashion that is well designed for extensibility.
>>> 
>>> This sounds more like an argument for having sealed classes than not. As 
>>> the proposal points out in the motivation, if the base class is not 
>>> designed with subclassing in mind then overriding methods can result in 
>>> unintended behavior (e.g. crashing, or other bugs).
>> 
>> But I think the counter argument is, what if you need to fix or workaround 
>> unintended behavior of the class you’re trying to use?
> 
> Typically you modify something open source - 99% of which is on GitHub. IMHO 
> the best way is to either fork it and perhaps submit a pull request with the 
> fix.
> 
> But I understand that this is not always possible...

I am a professional dev, and i rarely have the time (or even the legal right) 
to push back the changes i make to public code... the objc world is IMVHO very 
far from the professional open source culture that exists around other 
languages... so far the swift world is very embryonic. Sealing by default looks 
to me like a miss judgement of the maturity of the ecosystem.

> 
>> 
>> l8r
>> Sean
>> 
>> ___
>> 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] [Proposal] Sealed classes by default

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 4:52 PM, Mark Lacey <mark.la...@apple.com> wrote:
> 
> 
>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> -1 for the fact that if all devs can write working code, fewer can do it in 
>> a clear structured fashion that is well designed for extensibility.
> 
> This sounds more like an argument for having sealed classes than not. As the 
> proposal points out in the motivation, if the base class is not designed with 
> subclassing in mind then overriding methods can result in unintended behavior 
> (e.g. crashing, or other bugs).
> 

The pb i am referencing is devs who think their code is designed for extension 
but ends up being awkward or incompletely so. In my exp this is true of lots of 
(most) libs, including prominent projects. I got this sense over the years that 
a lot if newb designers want to play gods by showing how well they can juggle 
the different levels of privacy/locking in a language to create great 
extensible codebases.. and after getting burned a few times by their inability 
to think holistically about all possible codepaths, they become more humble and 
write more straightforward code that in the end becomes more extensible.

Crashing because of me deciding to extend something not ready for should remain 
my responsibility, because in the end this is no different than my own code 
crashing because of my bugs. I think it should be everyone's responsibility to 
make sure we pay attention when drinking hot coffee, not the responsibility of 
mcDonald to write in caps on their cups that hot liquids tend to cause burns. 

> Mark
> 
>> A couple months ago I even ran into difficulties when trying to extend 
>> AlamoFire because some things had not been designed as cleanly as they could 
>> have been to make extending it easy. So if the default is now that 
>> everything becomes non-extensible but default, it is going to complicate 
>> (and partially defeat the purpose of) reusing libraries.
>> Regards
>> (From mobile)
>> 
>>> On Jun 28, 2016, at 2:11 AM, Michael Ilseman via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> I was also referring to how we present Objective-C classes in Swift. That 
>>> is, if a Swift user tries to subclass an Objective-C-imported class, then 
>>> we’d take into account sealed-ness in order to issue an error/warning, etc. 
>>> If you are also proposing a Clang attribute for this, e.g. ‘swift_sealed’, 
>>> to import as sealed (meaning issue an error if Swift users try to subclass 
>>> it), then that should be spelled out as well. I don’t have an opinion on 
>>> whether this is a good idea yet, just pointing out some more directions to 
>>> explore. In general it feels like your proposal could use more fleshing out.
>>> 
>>> 
>>>> On Jun 27, 2016, at 5:08 PM, Javier Soto <javier@gmail.com> wrote:
>>>> 
>>>> That is a very good point, it should be explicitly mentioned in the 
>>>> proposal. My thought would be that since in the Obj-C runtime it's not 
>>>> possible to guarantee a class won't have subclasses, or that a method is 
>>>> not overriden, Obj-C classes would be imported as open. 
>>>> 
>>>> On the Swift side, I think today it's possible to declare a "public final 
>>>> @objc class", but you can still inherit from it from Obj-C, right? My 
>>>> hunch would be that that should be disallowed, but perhaps there's a 
>>>> reason why it's allowed today. 
>>>> On Mon, Jun 27, 2016 at 4:25 PM Michael Ilseman <milse...@apple.com> wrote:
>>>>> Could you elaborate on how we should treat classes imported from 
>>>>> Objective-C or CF-style C? That is, do we always annotate them as being 
>>>>> “open” because those paradigms permit subclassing anywhere, or do you 
>>>>> propose some kind of recommended “sealed” audit, or what?
>>>>> 
>>>>> 
>>>>>> On Jun 27, 2016, at 3:40 PM, Javier Soto via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>> 
>>>>>> Hello!
>>>>>> 
>>>>>> I sent this as a PR on the swift-evolution repo, but we never had any 
>>>>>> discussion about it on-list, besides a long time ago. Here's the first 
>>>>>> draft of the proposal:
>>>>>> 
>>>>>> 
>>>>>> Sealed classes by default
>>&g

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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)
> On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution 
>  wrote:
> 
> Anton Zhilin: That is one of the points if I’m not mistaken. Sealed
> means that with whole-module-optimization the compiler can optimise
> more things as it can treat it as final for other modules.
> 
> L. Mihalkovic: Could you give an example of what exactly do you mean?
> I know one of the reasons behind the proposal is to actually improve
> those situations by forcing us to think more on customisation when
> designing APIs.

In many situation it has been my experience that libraries can be extended 
DESPITE their authors, rather than only thanks to the skills the authors  have 
shown in planning for the future. It is what happened to me with AlamoFire, 
where i was able to extend it because some cracks existed which let me do 
something the designers did not think about (to me it was a lack of imagination 
to not have anticipated what i wanted to do).

So if this can happen with a lib made by very experienced/talented developers, 
then imagine what happens with far less skilled developers.. it will mean 
having to copy code in order extend. It may sound pessimistic, but if u had 
seen as much bad code as i have seen, you might understand the view i am 
sharing.

What's worse is that objc is not particularly conducive to good software 
architecture (it is a bit like perl and javascript where anything can be 
touched from anywhere, and has a limited set of constructs compared to c++, 
scala, java, c#, swift). So i do not believe that it has prepared objc devs to 
suddenly become great code designers with a language that has multiples levels 
of scoping/nesting (i would not use most of the swift libs i have seen on 
github to teach software design).

Hence my conclusion that defaulting to sealed may be giving too much credit to 
the code that is currently available for reuse.


> 
> On Tue, Jun 28, 2016 at 12:44 PM, Anton Zhilin via swift-evolution
>  wrote:
>> Does `sealed` allow for any optimizations? Maybe somehow devirtualizing
>> method calls?
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Alejandro Martinez
> http://alejandromp.com
> ___
> 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] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 12:25 AM, Dave Abrahams  wrote:
> 
> 
>> on Mon Jun 27 2016, "L. Mihalkovic"  wrote:
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jun 27, 2016, at 8:39 AM, Dave Abrahams  wrote:
>>> 
>>> 
>>> on Fri Jun 24 2016, Andrew Trick  wrote:
>>> 
> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution
>  wrote:
> 
>> On Jun 24, 2016, at 11:17 AM, L. Mihalkovic
>> > > wrote:
>> 
>> I like the watch-what-you-wish-for warning of unsafeCast.
> 
> I’ll try porting stdlib to the “UnsafeRawPointer.unsafeCast(to:
> T.Type)” syntax and see how bad it is.
 
 I don't think there's a clear winner here. Let me enumerate some
 options.
 
 Option (1) UnsafePointer(cast: UnsafeRawPointer)
>>> 
>>> The problem with this one is that T can be deduced based on type
>>> context.  I think we ought to move away from that for operations like
>>> this one.
>>> 
 Option (2) UnsafePointer(_: UnsafeRawPointer, to: T.self)
>>> 
>>> I think you mean T.Type, not T.self, because this looks like a declaration.
>>> 
>>> To evaluate, you have to look at the use-site:
>>> 
>>>   let p = UnsafePointer(r, to: Int.self)
>>> 
>>> I don't find “to” to be descriptive enough.  Maybe
>> 
>> toType
>> 
>>> 
>>>   let p = UnsafePointer(r, pointee: Int.self)
>> 
>> I find pointee a total aberation :)
>> 
>>> 
>>> is better.  But I hate that the language doesn't give us a way to say
>>> “don't deduce generic parameters here.”  This is the only syntax that
>>> feels right, IMO:
>>> 
>>>   let p = UnsafePointer(r)
>>> 
 Option (3) UnsafeRawPointer.unsafeCast(to: T.Type) ->
 UnsafePointer
>>> 
>>>   r.unsafeCast(to: Int.self)
>>> 
>>> I don't see adding “unsafe” to the name of the operation as adding
>>> anything.  It isn't any more unsafe than other UnsafeRawPointer
>>> operations.  
>> 
>> It is unsafe in the sense that there are no guarantees that it is a
>> sensible thing to do.
> 
> Just like most of the other operations on UnsafeRawPointer, which is my
> point.
> 
>> I guess that means it is more 'noguaranteeexplicitorimpliedapplied' in
>> the sense that it will like mechanically work, even if it produce an
>> aberation as a result
>> 
>>> Also, it reads like we're casting the raw pointer to an
>>> Int, rather than to an UnsafePointer.
>> 
>> Really good one... But then instead of 'to' or 'pointee', something
>> along the lines of 'wrappedType', which lookes a little less
>> balerina-ish than pointee.
> 
> A pointer does not wrap its pointee.

Mix a->b & from b
  let p = UnsafePointer(r, pointee: Int.self)
  let p = UnsafePointer(r, wrappedType: Int.self)

Purely a->b 
  let p = UnsafePointer(r, toObjectOfType: Int.self)
  let p = UnsafePointer(r, targetType: Int.self)
  let p = UnsafePointer(r, to: Int.self)
  let p = UnsafePointer(r, toType: Int.self)  
  let p = UnsafePointer(r, destinationType: Int.self)

You are of course absolutely right about wrappedType :)

I just think (for no other excuse than years of c) that when i think about a 
pointer i think of it directionally. And my unease comes from pointee suddenly 
shifting (for me) the view point: i suddenly have to shift to seeing the world 
from the other side. All the words i was trying (with the exception of 
wrappedType which i kept in the first group) share the  FromSourceToDestination 
connotation that i implicitly associate with pointers. But this is just me and 
this is purely subjective. Maybe it is time i break this mental model... I 
still find pointee a little too Bolshoi for my taste (nothing i wont get used 
to though).

>>> Also, how do you get an
>>> UnsafeMutablePointer?
>>> 
 Option (4) unsafeCast(rawPointer: UnsafeRawPointer, to: T.self) ->
 UnsafePointer
>>> 
>>> This one won't read correctly for the same reasons as #3.
>>> 
>>>   r.cast(to: UnsafePointer.self)
>>> 
>>> works better for me than any of the alternatives given our inability to
>>> get the One True Syntax.
>>> 
 ---
 Option (3) is the most explicit and searchable, and forces
 UnsafeRawPointer to be spelled out in the conversion (unless you
 already have a raw pointer).
>>> 
>>> Huh?  I'm confused here.  What you wrote looks like it's intended to be
>>> a regular method, in which case of course invoking it would require a raw
>>> pointer and wouldn't force you to write UnsafeRawPointer out anywhere.
>>> 
>>> The only way it could force you to write UnsafeRawPointer would be if it
>>> was a static method, but in that case it has too few arguments.
>>> 
 I like this because conceptually, you need to cast to a raw pointer
 before casting to a new pointee type, and casting a raw pointer to a
 typed pointer carries important semantics beyond simply converting to
 a typed pointer. The main problem with Option (3) is 

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 28, 2016, at 12:18 AM, Andrew Trick  wrote:
> 
> 
>>> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic  
>>> wrote:
>>> 
>>>  think you mean T.Type, not T.self, because this looks like a declaration.
>>> 
>>> To evaluate, you have to look at the use-site:
>>> 
>>>   let p = UnsafePointer(r, to: Int.self)
>>> 
>>> I don't find “to” to be descriptive enough.  Maybe
>> 
>> toType
>> 
>>> 
>>>   let p = UnsafePointer(r, pointee: Int.self)
>> 
>> I find pointee a total aberation :)
>> 
>>> 
>>> is better.  But I hate that the language doesn't give us a way to say
>>> “don't deduce generic parameters here.”  This is the only syntax that
>>> feels right, IMO:
>>> 
>>>   let p = UnsafePointer(r)
>>> 
 Option (3) UnsafeRawPointer.unsafeCast(to: T.Type) ->
 UnsafePointer
>>> 
>>>   r.unsafeCast(to: Int.self)
>>> 
>>> I don't see adding “unsafe” to the name of the operation as adding
>>> anything.  It isn't any more unsafe than other UnsafeRawPointer
>>> operations.  
>> 
>> It is unsafe in the sense that there are no guarantees that it is a sensible 
>> thing to do. I guess that means it is more 
>> 'noguaranteeexplicitorimpliedapplied' in the sense that it will like 
>> mechanically work, even if it produce an aberation as a result
>> 
>>> Also, it reads like we're casting the raw pointer to an
>>> Int, rather than to an UnsafePointer.
>> 
>> Really good one... But then instead of 'to' or 'pointee', something along 
>> the lines of 'wrappedType', which lookes a little less balerina-ish than 
>> pointee.
> 
> 
> Any gripes about this syntax?
> 
> let ptrB = UnsafeRawPointer(ptrA).cast(to: UnsafePointer.Type)
> 
> It meets the goal of being perfectly explicit. We can add convenience APIs 
> for certain cases later.
> 
> -Andy

I have to say, there are many situations when writing java code where i wished 
List.class existed.. instead I'd resort to xxx(List.class, Int.class) or 
to generic reflection on a abstract type token. 
So this DEFINITELY floats my boat As you say, it is the most accurate 
depiction of what truly happens.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

-1 for the fact that if all devs can write working code, fewer can do it in a 
clear structured fashion that is well designed for extensibility. A couple 
months ago I even ran into difficulties when trying to extend AlamoFire because 
some things had not been designed as cleanly as they could have been to make 
extending it easy. So if the default is now that everything becomes 
non-extensible but default, it is going to complicate (and partially defeat the 
purpose of) reusing libraries.
Regards
(From mobile)

> On Jun 28, 2016, at 2:11 AM, Michael Ilseman via swift-evolution 
>  wrote:
> 
> I was also referring to how we present Objective-C classes in Swift. That is, 
> if a Swift user tries to subclass an Objective-C-imported class, then we’d 
> take into account sealed-ness in order to issue an error/warning, etc. If you 
> are also proposing a Clang attribute for this, e.g. ‘swift_sealed’, to import 
> as sealed (meaning issue an error if Swift users try to subclass it), then 
> that should be spelled out as well. I don’t have an opinion on whether this 
> is a good idea yet, just pointing out some more directions to explore. In 
> general it feels like your proposal could use more fleshing out.
> 
> 
>> On Jun 27, 2016, at 5:08 PM, Javier Soto  wrote:
>> 
>> That is a very good point, it should be explicitly mentioned in the 
>> proposal. My thought would be that since in the Obj-C runtime it's not 
>> possible to guarantee a class won't have subclasses, or that a method is not 
>> overriden, Obj-C classes would be imported as open. 
>> 
>> On the Swift side, I think today it's possible to declare a "public final 
>> @objc class", but you can still inherit from it from Obj-C, right? My hunch 
>> would be that that should be disallowed, but perhaps there's a reason why 
>> it's allowed today. 
>> On Mon, Jun 27, 2016 at 4:25 PM Michael Ilseman  wrote:
>>> Could you elaborate on how we should treat classes imported from 
>>> Objective-C or CF-style C? That is, do we always annotate them as being 
>>> “open” because those paradigms permit subclassing anywhere, or do you 
>>> propose some kind of recommended “sealed” audit, or what?
>>> 
>>> 
 On Jun 27, 2016, at 3:40 PM, Javier Soto via swift-evolution 
  wrote:
 
>>> 
 Hello!
 
 I sent this as a PR on the swift-evolution repo, but we never had any 
 discussion about it on-list, besides a long time ago. Here's the first 
 draft of the proposal:
 
 
 Sealed classes by default
 Introduction
 
 Introduce a new sealed class modifier that makes classes and methods final 
 outside of the module they're declared in, but non-final within the module.
 
 Motivation
 
 It is not uncommon to have a need for a reference type without needing 
 inheritance. Classes must be intentionally designed to be subclassable, 
 carefully deciding which methods are the override entry-points such that 
 the the behavior remains correct and subclasses respect the Liskov 
 substitution principle.
 Defaulting to non-final allows the author of a class to accidentally leave 
 the visible methods open for overrides, even if they didn't carefully 
 consider this possibility.
 Requiring that the author of a class mark a class as open is akin to 
 requiring symbols to be explicitly public: it ensures that a conscious 
 decision is made regarding whether the ability to subclass a class is part 
 of the API.
 Proposed solution
 
 New sealed (actual name pending bike-shedding) class modifier for classes 
 and methods which marks them as only overridable within the module they're 
 declared in.
 sealed becomes the default for classes and methods.
 New open (actual name pending bike-shedding) class modifier to explicitly 
 mark a class or a method as overridable.
 Detailed design
 
 Code Examples:
 
 /// ModuleA:
 
 /// This class is `sealed` by default.
 /// This is equivalent to `sealed class SealedParentClass`
 class SealedParentClass {
 /// This method is `sealed` by default`.
 func foo()
 
 /// This raises a compilation error: a method can't have a 
 "subclassability"
 /// level higher than that of its class.
 open func bar()
 
 /// The behavior of `final` methods remains unchanged.
 final func baz()
 }
 
 open class OpenParentClass {
 /// This method is `sealed` by default`.
 func foo()
 
 /// Overridable methods in an `open` class must be explicitly marked 
 as `open`.
 open func bar()
 
 /// The behavior of a `final` method remains unchanged.
 final func baz()
 }
 
 /// The behavior of `final` classes remains unchanged.
 final class FinalClass { }
 

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 27, 2016, at 11:59 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> “The access modifier of an extension sets the default modifier of its members 
> which has no modifier applied to them.”

I get it now.. "which do not have their own localy defined modifier"
> public extension SomeType {
> func extensionMember() {}
> }
> “If there the extension has no access modifier, then the default modifier of 
> its members which has no explicit modifier will be internal if the extended 
> type is either public or internal, or it will be private when the extended 
> type is private(analogous for fileprivate).”
> // First
> public/internal struct A {}
> 
> extension A {
>  
> /* internal */ func member() {}
> }
> 
> // Second
> private struct B {}
> 
> extension B {
>  
> /* private */ func member() {}
> }
> My English isn’t great, please don’t blame me for that. Feel free to correct 
> me. I’d appreciate that. :)
> 
I didn't, i just asked for clarification (i truly did not get the meaning). 


> But more importantly, I was under the impression that Doug had hinted that 
> private (or likely more generally scoped) conformance on extension was a 
> slipery slope with important impact on runtime performance.
> I’m not an expert in this area, I really cannot tell. And I don’t want to dig 
> in all these thousands of emails to find his talk. FWIW not every proposal 
> does know the impact which will happen behind the scene. Even some simple 
> change might have a huge impact (I don’t say this proposal is simple).
> 
I am no expert myself. I just happened to remember what looked like a partial 
answer. The generic manifesto has a section on 'Private Conformances' that 
gives some interesting clues about what's involved in scoping extension based 
conformances.

> My personal vision of the access control is clarity and consistency. It would 
> be much easier to have the same access control behavior on extensions like on 
> classes, enums and structs.
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> ___
> 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] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 27, 2016, at 8:39 AM, Dave Abrahams  wrote:
> 
> 
> on Fri Jun 24 2016, Andrew Trick  wrote:
> 
>>> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution
>>>  wrote:
>>> 
 On Jun 24, 2016, at 11:17 AM, L. Mihalkovic
 > wrote:
 
 I like the watch-what-you-wish-for warning of unsafeCast.
>>> 
>>> I’ll try porting stdlib to the “UnsafeRawPointer.unsafeCast(to:
>>> T.Type)” syntax and see how bad it is.
>> 
>> I don't think there's a clear winner here. Let me enumerate some
>> options.
>> 
>> Option (1) UnsafePointer(cast: UnsafeRawPointer)
> 
> The problem with this one is that T can be deduced based on type
> context.  I think we ought to move away from that for operations like
> this one.
> 
>> Option (2) UnsafePointer(_: UnsafeRawPointer, to: T.self)
> 
> I think you mean T.Type, not T.self, because this looks like a declaration.
> 
> To evaluate, you have to look at the use-site:
> 
>let p = UnsafePointer(r, to: Int.self)
> 
> I don't find “to” to be descriptive enough.  Maybe

toType

> 
>let p = UnsafePointer(r, pointee: Int.self)

I find pointee a total aberation :)

> 
> is better.  But I hate that the language doesn't give us a way to say
> “don't deduce generic parameters here.”  This is the only syntax that
> feels right, IMO:
> 
>let p = UnsafePointer(r)
> 
>> Option (3) UnsafeRawPointer.unsafeCast(to: T.Type) ->
>> UnsafePointer
> 
>r.unsafeCast(to: Int.self)
> 
> I don't see adding “unsafe” to the name of the operation as adding
> anything.  It isn't any more unsafe than other UnsafeRawPointer
> operations.  

It is unsafe in the sense that there are no guarantees that it is a sensible 
thing to do. I guess that means it is more 
'noguaranteeexplicitorimpliedapplied' in the sense that it will like 
mechanically work, even if it produce an aberation as a result

> Also, it reads like we're casting the raw pointer to an
> Int, rather than to an UnsafePointer.

Really good one... But then instead of 'to' or 'pointee', something along the 
lines of 'wrappedType', which lookes a little less balerina-ish than 
pointee.

>  Also, how do you get an
> UnsafeMutablePointer?
> 
>> Option (4) unsafeCast(rawPointer: UnsafeRawPointer, to: T.self) ->
>> UnsafePointer
> 
> This one won't read correctly for the same reasons as #3.
> 
>r.cast(to: UnsafePointer.self)
> 
> works better for me than any of the alternatives given our inability to
> get the One True Syntax.
> 
>> ---
>> Option (3) is the most explicit and searchable, and forces
>> UnsafeRawPointer to be spelled out in the conversion (unless you
>> already have a raw pointer).
> 
> Huh?  I'm confused here.  What you wrote looks like it's intended to be
> a regular method, in which case of course invoking it would require a raw
> pointer and wouldn't force you to write UnsafeRawPointer out anywhere.
> 
> The only way it could force you to write UnsafeRawPointer would be if it
> was a static method, but in that case it has too few arguments.
> 
>> I like this because conceptually, you need to cast to a raw pointer
>> before casting to a new pointee type, and casting a raw pointer to a
>> typed pointer carries important semantics beyond simply converting to
>> a typed pointer. The main problem with Option (3) is that optional raw
>> pointers can't be converted naturally (without using `map`).
> 
>  r ?? someExpressionUsing(r!)
> 
> best I can do.
> 
>> Another thing I'm a little nervous about is confusing a cast of the
>> pointer value with a cast of the pointee type:
>> 
>>  `unsafeBitCast(rawPtr, to: Int.self)`
>> 
>> is very different from
>> 
>>  `rawPtr.unsafeCast(to: Int.self)`
>> 
>> Does this need to be clarified?
> 
> Yes!
> 
>> If so, we can go back to the `toPointee` label that I proposed
>> earlier.
>> 
>> With that in mind, Option(4) is starting to look pretty good.
>> 
>> Examples:
>> 
>> ---
>> Case 1: casting a raw pointer as an argument
> 
> Use sites! (yay)...
> 
>> func foo(_: UnsafePointer)
>> 
>> let rawPtr = UnsafeRawPointer(...)
>> 
>> (1) foo(UnsafePointer(cast: rawPtr))
>> 
>> (2) foo(UnsafePointer(rawPtr, to: A.self))
>> 
>> (3) foo(rawPtr.unsafeCast(to: A.self))
>> 
>> (4) foo(unsafeCast(rawPointer: rawPtr, to: A.self))
> 
> 
> foo(rawPtr.cast(to: UnsafePointer.self))
> 
>> ---
>> Case 2: "recasting" a typed pointer argument
>> 
>> Note that typed pointer arguments are implicitly cast to raw pointer
>> arguments, so the conversion from PtrB to raw is implicit.
>> 
>> func foo(_: UnsafePointer)
>> 
>> let ptrB = UnsafePointer(...)
>> 
>> (1) foo(UnsafePointer(cast: ptrB))
>> 
>> (2) foo(UnsafePointer(ptrB, to: A.self))
>> 
>> (3) foo(UnsafeRawPointer(ptrB).unsafeCast(to: A.self))
>> 
>> (4) foo(unsafeCast(rawPointer: ptrB, to: A.self))
> 
> foo(UnsafeRawPointer(ptrB).cast(to: UnsafePointer.self))
> 
> I don't believe in making 

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> My 2c:
> 
> This proposal is made more appealing to me because it is not simply a 
> 'beginners will get confused' issue. 
> 
> I have written tens of thousands of lines of Swift from Swift 1 to the Swift 
> 3 preview and I still can't shake occasionally accidentally capturing `self` 
> strongly when I, for example, assign a closure as a listener/action to a UI 
> component.

The problem of is that it is easier for an app to survive an accidental extra 
capture than it is for it the survive a missing one.. So if this is really for 
beginners, then it is much better to keep the current behavior which will lead 
them to have leaky apps, than it is to give them apps whre objects will vanish 
from under their feet... granted neither is good to begin with.


> 
> To spin off of Christopher's last email, my proposal is thus: we could 
> include the original proposal (without numbered addendums) and use tooling, 
> but have it alleviate the burden another way: have the tooling insert 
> `[strong self]` by default when autocompleting a block.
> 
> BTW, @Manuel Krebber: this proposal would not affect your run-of-the-mill map 
> statement. array.map { object in object.property } requires no explicit 
> capture since object is intuitively strongly captured there.
> 
> What do we think? Worth discussing?
> 
> On Mon, Jun 27, 2016 at 12:10 PM Christopher Kornher via swift-evolution 
>  wrote:
 On Jun 26, 2016, at 11:22 PM, Charlie Monroe via swift-evolution 
  wrote:
 
 All object references used within a closure must unwrap successfully for 
 the closure to execute.
>>> I agree with the logic of this proposal, but this is the confusing part or 
>>> a part that I slightly disagree with.
>>> 
>>> By this logic, the block won't be invoked if all captured variables can't 
>>> be unwrapped, which is definitely confusing to the newcomer (to whom this 
>>> is partially targetted as you've mentioned) if he puts a breakpoint in it 
>>> and doesn't get executed even when he's explicitely invoking it somewhere.
>>> 
>>> On the other hand, when it crashes, it gives him some idea that something's 
>>> wrong.
>> 
>> Tooling could alleviate some of this mystery. For example:
>> 
>> 1) In Xcode and other GUIs, closures that will not be executed could be 
>> greyed-out, perhaps with the reason overlaid on the closure perhaps this 
>> would only happen when a breakpoint was set within the closure. Perhaps the 
>> app could break on the on breakpoints within non-executing closures and 
>> notify the user that the closure did not execute.
>> 
>> 2) Debugger console commands could be added to describe the execution state 
>> of closures in scope and closure variables.
>> 
>> 3) Debug apps could bottleneck all closures through a function that that can 
>> be break-pointed. Breakpoints could be edited to filter on specific 
>> closures. 
>> 
>> 4) Some runtime switches could be added to enable verbose login modes for 
>> closures.
>> 
>> I don’t think that this is an insurmountable problem. There are many 
>> features of modern applications that are difficult to debug.
>> 
>>> 
>>> 
 
 I believe that these are safe, sensible and understandable rules that will 
 eliminate the need for capture lists for many closures. What do you think?
 
 
 ___
 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

[L. Mihalkovic via swift-evolution]

"The access modifier of an extension sets the default modifier of its members 
which has no modifier applied to them."

I cannot understand the sentence, or the following:

"If there the extension has no access modifier, then the default modifier of 
its members which has no explicit modifier will be internal if the extended 
type is either public or internal, or it will be private when the extended type 
is private(analogous for fileprivate)."

But more importantly, I was under the impression that Doug had hinted that 
private (or likely more generally scoped) conformance on extension was a 
slipery slope with important impact on runtime performance.

Regards
(From mobile)

> On Jun 27, 2016, at 2:39 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I completely rewritten the proposal, you can read the formatted version here:
> 
> https://github.com/DevAndArtist/swift-evolution/blob/19f2583209a5763880e6f6fa6738ea0c6011f2d6/proposals/-extensions-access-modifiers.md
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 27. Juni 2016 um 12:58:53, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> And yet another correction of the default protocol implementations part of 
>> my reply.
>> 
>> The imported module is correct, but the default implementation is not 
>> imported (I relied on Xcode which didn’t raise an error before I started 
>> building the project where I was using the module, and I didn’t build it at 
>> the first time).
>> 
>> So we’d need to implement foo by ourself.
>> 
>> struct B : A {
>>   
>> public func foo() {}
>> }   
>> The rest of my reply should be fine. With the same access control it would 
>> be more clearer and intuitive how the extension will be imported.
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 27. Juni 2016 um 10:38:12, Adrian Zubarev 
>> (adrian.zuba...@devandartist.com) schrieb:
>> 
>>> Lets examine the impact on default protocol implementations:
>>> 
>>> Currently we have this behavior:
>>> 
>>> public protocol A {
>>> func foo()
>>> }
>>> 
>>> extension A {
>>> func foo() { /* implement */ }
>>> }
>>> The imported version would look like this.
>>> 
>>> public protocol A {
>>> public func foo()
>>> }
>>> As the module user you have no clue that there might be a default 
>>> implementation, but you sill will be able to use it, because when 
>>> conforming to A you don’t have to implement foo. This implicitly signals 
>>> you that there is indeed a default implemenation
>>> 
>>> struct B : A {} // This will be enough
>>> 
>>> A().foo() // this is fine
>>> One could signal the module user that there is a default implementation by 
>>> making the extension explicit public as well.
>>> 
>>> // explicitly marked as public to grant visibility to
>>> // the default implementation extension bag
>>> public extension A {
>>>
>>> /// will do something cool
>>> func foo() { /* implement */ }
>>> }
>>> The result of the imported module would change and look like this:
>>> 
>>> public protocol A {
>>> public func foo()
>>> }
>>> 
>>> extension A {
>>>
>>> /// will do something cool
>>> public func foo()
>>> }
>>> With the proposed change all default implementations will become visible by 
>>> default and I think this is great step as well.
>>> 
> 
> ___
> 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-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

As i said, already deeply regretted mentioning P|Q as on closer examination of 
a well known precedent it is very realistic to have P only.
Apologize again for not doing the due dilligence before pressing send.
(From mobile)

> On Jun 27, 2016, at 7:04 PM, Austin Zheng  wrote:
> 
> I think the rationale thread for the original version of this proposal pretty 
> much shut down the possibility of disjunctive type constraints. In fact, the 
> primary argument against '&' was that it would encourage conversations about 
> '|'.
> 
> It's also been added to the commonly rejected proposals list: 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> 
>> On Mon, Jun 27, 2016 at 9:48 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> > On Jun 25, 2016, at 12:00 AM, L. Mihalkovic  
>> > wrote:
>> >
>> > Inline
>> > Regards
>> > (From mobile)
>> >
>> >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>> >>  wrote:
>> >>
>> >>
>> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
>> >>>  wrote:
>> >>>
>> >>> [Proposal: 
>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>> >>>  ]
>> >>>
>> >>> I’ve gone on record before as against this syntax, although when I set 
>> >>> out earlier today to record my usual rebuttal I found that it really was 
>> >>> mostly a matter of taste. Yes, this looks weird to me:
>> >>>
>> >>> let callback: (Data) -> NSCoding & NSCopying
>> >>>
>> >>> but I’m sure the infix ‘->’ for functions looked weird to everyone the 
>> >>> first time they saw it as well, and it really is pretty clear in 
>> >>> argument position.
>> >>
>> >> We could conceivably bracket the 'where' constraints somewhere. It's nice 
>> >> not to have to punish the common case syntax. In my personal ideal vision 
>> >> of the world, I'd like to see us support opening existentials via 
>> >> path-dependent types (e.g., let a: Collection; let element: a.Element). 
>> >> If we support them in decl-level 'where' clauses, we provide a nice, 
>> >> clean syntax for complex generic relationships that doesn't require angle 
>> >> brackets or per-existential where clauses at all, something like:
>> >>
>> >>   func intersect(a: Collection, b: Collection) -> Collection
>> >>   where a.Element == b.Element, b.Element == return.Element {
>> >>   }
>> >>
>> >> which doesn't completely define away the need for 'where' as part of 
>> >> existential types, but would shrink it quite a bit.
>> >
>> > For some reason it had not clicked until your 'path dependent type' 
>> > reference how reminicent of (U+00B7) this is. I watched nada's 2014 
>> > presentation again... but then it means intersection types would add a 
>> > lot... you guys seem ok to add P now, so why not take that opportunity 
>> > to allow P|Q at the same time. Does it also mean that you might consider 
>> > at some point expanding 'assoctype U'  into:  T where <:U , :>U  opening 
>> > the door to lower/higher type bounds?
>> 
>> Let's not rathole on the P|Q thing. Disjunctions are difficult to make much 
>> sense of in a parametric type system like ours; there are plenty of other 
>> threads on this mailing list discussing it.
>> 
>> -Joe
>> ___
>> 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-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

Inline

Regards
LM
(From mobile)

> On Jun 27, 2016, at 6:48 PM, Joe Groff  wrote:
> 
> 
>> On Jun 25, 2016, at 12:00 AM, L. Mihalkovic  
>> wrote:
>> 
>> Inline
>> Regards
>> (From mobile)
>> 
>>> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
  wrote:
 
 [Proposal: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
  ]
 
 I’ve gone on record before as against this syntax, although when I set out 
 earlier today to record my usual rebuttal I found that it really was 
 mostly a matter of taste. Yes, this looks weird to me:
 
 let callback: (Data) -> NSCoding & NSCopying
 
 but I’m sure the infix ‘->’ for functions looked weird to everyone the 
 first time they saw it as well, and it really is pretty clear in argument 
 position.
>>> 
>>> We could conceivably bracket the 'where' constraints somewhere. It's nice 
>>> not to have to punish the common case syntax. In my personal ideal vision 
>>> of the world, I'd like to see us support opening existentials via 
>>> path-dependent types (e.g., let a: Collection; let element: a.Element). If 
>>> we support them in decl-level 'where' clauses, we provide a nice, clean 
>>> syntax for complex generic relationships that doesn't require angle 
>>> brackets or per-existential where clauses at all, something like:
>>> 
>>>  func intersect(a: Collection, b: Collection) -> Collection
>>>  where a.Element == b.Element, b.Element == return.Element {
>>>  }
>>> 
>>> which doesn't completely define away the need for 'where' as part of 
>>> existential types, but would shrink it quite a bit.
>> 
>> For some reason it had not clicked until your 'path dependent type' 
>> reference how reminicent of (U+00B7) this is. I watched nada's 2014 
>> presentation again... but then it means intersection types would add a 
>> lot... you guys seem ok to add P now, so why not take that opportunity to 
>> allow P|Q at the same time. Does it also mean that you might consider at 
>> some point expanding 'assoctype U'  into:  T where <:U , :>U  opening the 
>> door to lower/higher type bounds?
> 
> Let's not rathole on the P|Q thing. Disjunctions are difficult to make much 
> sense of in a parametric type system like ours; there are plenty of other 
> threads on this mailing list discussing it.

Already retracted the P|Q as bringing absolutely nothing required in the 
foreseeable future. Apologies again for not having the presence of mind to see 
it before clicking send.

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

Re: [swift-evolution] Revisiting SE-0041 Names

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>> on Wed Jun 22 2016, Matthew Johnson  wrote:
>> 
 On Jun 22, 2016, at 1:55 PM, Dmitri Gribenko
  wrote:
 
 On Wed, Jun 22, 2016 at 11:04 AM, Erica Sadun via swift-evolution
 >> 
 >
 wrote:
> Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
> 
> Rejection: "The feedback on the proposal was generally positive about the
> idea of renaming these protocols, but the specific names in the proposal 
> are
> not well received, and there is no apparent confluence in the community on
> better names.  The core team prefers discussion to continue -- if/when 
> there
> is a strong proposal for a better naming approach, we can reconsider
> renaming these."
> 
> John McCall: "To be clear, I don't care about the name.  If you want to
> rename IntegerLiteralConvertible to IntegerLiteral or whatever, I won't 
> drag
> the conversation into the muck again. :)  It's the design of the
> requirements that I'm pretty opposed to revisiting."
> 
> The Problem: This is really the last chance to rationalize this across the
> language and to evaluate whether other protocol groups should have a core
> scheme for naming.
 
 Hi Erica,
 
 I would like to re-state the feedback from Dave Abrahams, Max Moiseev
 and me from the last time this was discussed.  Unfortunately I can't
 find the exact email, so I can't provide a link.
 
 - The "literal" protocols are not about conversion, they are about
 adopting a certain syntax provided by the language.  "Convertible" in
 the name is a red herring: a type can't be convertible from an integer
 literal because there is no "IntegerLiteral" entity in the type
 system.  The literal *becomes* typed as the corresponding literal type
 (e.g., Int or String), and as far as the user at the call site is
 concerned, there is no visible conversion (even if one is happening
 behind the scenes).
 
 Our suggestion was to focus on the "adopting the syntax" part.  We
 suggested moving the "literal convertible" protocols into a
 pseudo-namespace "Syntax".  It could be implemented like this:
 
 protocol _IntegerLiteralSyntax {}
 enum Syntax {
 typealias IntegerLiteral = _IntegerLiteralSyntax
 }
 
 And used like this:
 
 struct Int : Syntax.IntegerLiteral {}
>>> 
>>> I’m working on a draft of this proposal right now.  I have a couple 
>>> questions.  
>>> 
>>> First, I’d like to list the standard library team as co-authors if you
>>> desire because this is really your idea.  Let me know what you would
>>> prefer.
>>> 
>>> Second, I wonder if it might make more sense to name the protocols
>>> `Syntax.IntegerLiteralInitializable`.  Dave has opposed
>>> `Initializable` as a general convention because it implies pure syntax
>>> and doesn’t carry any semantics.  But in this case the semantics *are*
>>> essentially the syntax.  Erica pointed out to me off list that at the
>>> usage site the `Syntax.IntegerLiteral` names could confuse somebody
>>> into thinking in terms of *isa* rather than *can do* (i.e. Int is an
>>> IntegerLiteral rather than Int can be *initialized* with an
>>> IntegerLiteral).
>> 
>> Really, this is exactly the sense in which we want it to be interpreted.
>> It is *not* a capability.  There is no such thing as an IntegerLiteral
>> instance from which one can initialize an Int.  There are only syntactic
>> integer literals, which, given the right type context, can be-a Int.
>> The intializer one gets from the protocol is merely the mechanism used
>> by the compiler to create this Int.
> 
> That is a technically correct statement, but I think the model most 
> programmers will have (good or bad) is of initializing with an integer 
> literal.  I think this is evidenced to some degree by the feedback people are 
> providing on the names.

Perpetuating the wrong idea does not make it a good idea... There was Ptolemy 
and then there was Galileo.

> That said, I am trying to stay out of the fray of the bike shedding on this.  
> IMO the most important thing is to do *something* here as long as its 
> reasonable and the solution suggested by the standard library team is 
> definitely reasonable.  That is why I have written the proposal exactly as 
> the standard library team suggested.  :)  
> 
>> 
>>> 
>>> Please let me know if this name change would be acceptable to the
>>> standard library team or may be met with resistance.  I want this
>>> proposal to be 

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

[L. Mihalkovic via swift-evolution]

There was an exchange in the past on how extensions are very different from 
swift nominal/structural types, and Doug even shared how adding scoping to 
extensions is not a trivial task by a long shot. In this context, talking about 
unifying modifier behaviors does not make much sense to me. I am not sure i 
understand what motivates this change.
Regards
(From mobile)

> On Jun 26, 2016, at 8:59 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Proposal is moved to a git repo: 
> https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/-extensions-access-modifiers.md
> 
> I also updated a few things for readability.
> Revising access modifiers on extensions
> 
> Proposal: SE-
> Author: Adrian Zubarev
> Status: Awaiting review
> Review manager: TBD
> Introduction
> 
> One great goal for Swift 3 is to sort out any source breaking language 
> changes. This proposal aims to fix access modifier inconsistency on 
> extensions compared to other scope declarations types.
> 
> Swift-evolution thread: [Proposal] Revising access modifiers on extensions
> 
> Motivation
> 
> When declaring members on extensions which don’t have an explicit access 
> modifier in Swift 2.2, it is possible to create an implicitly public 
> extension by applying a public modifier to at least one extension member.
> 
> public struct A { … }
> 
> // Implicitly public  
> extension A {
> public var member1: SomeType { … }
>  
> // Implicitly internal  
> func member2() { … }
> }
> 
> // Implicitly internal
> extension A {
> 
> // Implicitly internal
> var member3: SomeType { … }
> }
> Furthermore in Swift 2.2 it is not allowed to apply an access modifier on 
> extensions when a type inheritance clause is present:
> 
> public protocol B { … }
> 
> // 'public' modifier cannot be used with
> // extensions that declare protocol conformances
> public extension A : B { … }
> Proposed solution
> 
> Allow access modifier on extensions when a type inheritance clause is present.
> 
> Remove the behavior of an implicit public extension.
> 
> This changes should make access modifier on extensions consistent to classes, 
> structs and enums (and SE–0025).
> 
> The current grammar will not change:
> 
> extension-declaration → access-level-modifieropt extension type-identifier 
> type-inheritance-clauseopt extension-body
> 
> extension-declaration → access-level-modifieropt extension type-identifier 
> requirement-clause extension-body
> 
> extension-body → { declarationsopt }
> 
> Iff the access-level-modifier is not present, the access modifier on 
> extensions should always be implicitly internal.
> 
> Impact on APIs:
> 
> Current version:
> 
> /// Implementation version
> ///
> 
> public protocol Y {
> func member()
> }
> 
> public struct X { … }
> 
> // Implicitly public
> extension X : Y {
> public func member() { ... }
>  
> // Implicitly internal
> func anotherMember() { ... }
> }
> 
> /// Imported modele version
> ///
> 
> public protocol Y {
> func member()
> }
> 
> public struct X { ... }
> 
> // Missing `public` modifier
> extension X : Y {
> public func member() { ... }
> }
> New Version:
> 
> /// Implementation version
> ///
> 
> public extension X : Y {
> public func member() { ... }
>  
> // Implicitly internal  
> func anotherMember() { ... }
> }
> 
> /// Imported modele version
> ///
> 
> public extension X : Y {
> public func member() { ... }
> }
> Impact on existing code
> 
> This is a source-breaking change that can be automated by a migrator, by 
> simply scanning the extension-body for at least one public modifier on its 
> members. Iff a public modifier was found on any member, the migrator can add 
> an explicit public modifier to the extension itself.
> 
> Alternatives considered
> 
> No other alternative were considered for this proposal.
> Rationale
> 
> On [Date], the core team decided to (TBD) this proposal. When the core team 
> makes a decision regarding this proposal, their rationale for the decision 
> will be written here.
> 
> 
> 
> 
> ___
> 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 25, 2016, at 8:48 PM, Thorsten Seitz  wrote:
> 
> 
>> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic :
>> 
>> 
>> 
>> Regards
>> (From mobile)
>> 
>>> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution 
>>>  wrote:
>>> 
>>> Sorry for the late reply — I had hoped to be able to think more deeply 
>>> about various points, 
>>> but I’m going to delay that instead of delaying the reply even more :-)
>>> 
>>> 
 Am 17.06.2016 um 19:04 schrieb Dave Abrahams :
 
 
 on Thu Jun 16 2016, Thorsten Seitz  wrote:
 
>> Am 13.06.2016 um 04:04 schrieb Dave Abrahams :
>> 
>> 
>> on Fri Jun 10 2016, Thorsten Seitz  wrote:
>> 
> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
> :
> 
> 
> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
> :
>>> 
> 
> on Wed Jun 08 2016, Jordan Rose  wrote:
> 
>>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>>>  wrote:
>>> 
>>> 
>>> on Wed Jun 08 2016, Thorsten Seitz
>> 
>>> >> >
>>> wrote:
>>> 
 Ah, thanks, I forgot!  I still consider this a bug, though (will 
 have
 to read up again what the reasons are for that behavior).
>>> 
>>> Yes, but in the case of the issue we're discussing, the choices are:
>>> 
>>> 1. Omit from the existential's API any protocol requirements that 
>>> depend
>>> on Self or associated types, in which case it *can't* conform to
>>> itself because it doesn't fulfill the requirements.
>>> 
>>> 2. Erase type relationships and trap at runtime when they don't 
>>> line up.
>>> 
>>> Matthew has been arguing against #2, but you can't “fix the bug” 
>>> without
>>> it.
>> 
>> #1 has been my preference for a while as well, at least as a starting
>> point.
> 
> I should point out that with the resyntaxing of existentials to
> Any, the idea that Collection's existential doesn't
> conform to Collection becomes far less absurd than it was, so maybe 
> this
> is not so bad.
 
 I think the problem is more that Any does not conform to
 a specific value for a type parameter T: Collection
 
 What I mean by this is that `Collection` denotes a type family, a
 generic parameter `T: Collection` denotes a specific (though
 unknown) member of that type family and `Any` denotes
 the type family again, so there is really no point in writing
 Any IMO.
 The type family cannot conform to T because T is just one fixed member 
 of it.
 It conforms to itself, though, as I can write
 let c1: Any = …
 let c2: Any = c1
 
 That’s why I think that we could just drop Any and simply 
 write Collection.
>>> 
>>> Let me expand that a bit:
>>> 
>>> Actually all this talk about existentials vs. generics or protocols
>>> vs. classes has had me confused somewhat and I think there are still
>>> some misconceptions present on this list sometimes, so I’ll try to
>>> clear them up:
>> 
>> There are several objectively incorrect statements here, and several
>> others with which I disagree.  I was hoping someone else would write
>> this for me, but since the post has such a tone of authority I feel I
>> must respond.
> 
> You are right, the tone of my post was not appropriate, for which I
> want to apologize sincerely.
 
 My fundamental disagreement is with the content, not the tone.
 
> I still believe my statements to be valid, though, and will respond to
> your arguments inline. Please don't get me wrong, I'm not trying to
> have an argument for the argument's sake. All I want is to contribute
> maybe a tiny bit to make Swift even better than it already is, by
> sharing ideas and thoughts not only from me but from the designs of
> other perhaps more obscure programming languages which I happen to
> have stumbled upon in the past (often with much delight).
 
 And I want you to know, even though I disagree with what you've written,
 that I very much appreciate the contribution you're making.
>>> 
>>> Thanks! I’m very glad about that!
>>> 
>>> 
 
>>> (1) misconception: protocols with associated types are somehow very
>>> different from generics
>>> 
>>> I don’t think 

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Don't you think that for no other reason than completeness it would make sense 
to document the metacircular definition I suggested? 

> On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> I replaced `precedencegroup` with `precedence` and added `Precedence` 
> suffix to all precedence group names. See:
> 
> https://github.com/Anton3/swift-evolution/blob/fix-operator-
> precedence/proposals/0077-operator-precedence.md
> 
> My feelings:
> 1. `precedencegroup` describes what it declares more precisely
> 2. `precedence` is shorter (partially compensating for longer names)
> 3. `precedence` can be correctly interpreted as "precedence level"
> 4. `precedence` looks nicer overall
> 
> 5. `Precedence` suffix is bulky. One must specify it in operator 
> declarations and in all relationships
> 6. All groups ending with adjectives may unambiguously drop the suffix
> 7. Number of such groups is small. New groups will tend to be named after 
> corresponding operators, and they will be noun-based
> 
> Questions:
> 1. Where else can we drop -Precedence?
> 2. Can we make more names end with adjectives?
> 
> ___
> 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-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> Sorry for the late reply — I had hoped to be able to think more deeply about 
> various points, 
> but I’m going to delay that instead of delaying the reply even more :-)
> 
> 
>> Am 17.06.2016 um 19:04 schrieb Dave Abrahams :
>> 
>> 
>> on Thu Jun 16 2016, Thorsten Seitz  wrote:
>> 
 Am 13.06.2016 um 04:04 schrieb Dave Abrahams :
 
 
 on Fri Jun 10 2016, Thorsten Seitz  wrote:
 
>>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution 
>>> :
>>> 
>>> 
>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution 
>>> :
> 
>>> 
>>> on Wed Jun 08 2016, Jordan Rose  wrote:
>>> 
> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
>  wrote:
> 
> 
> on Wed Jun 08 2016, Thorsten Seitz
 
>  >
> wrote:
> 
>> Ah, thanks, I forgot!  I still consider this a bug, though (will have
>> to read up again what the reasons are for that behavior).
> 
> Yes, but in the case of the issue we're discussing, the choices are:
> 
> 1. Omit from the existential's API any protocol requirements that 
> depend
> on Self or associated types, in which case it *can't* conform to
> itself because it doesn't fulfill the requirements.
> 
> 2. Erase type relationships and trap at runtime when they don't line 
> up.
> 
> Matthew has been arguing against #2, but you can't “fix the bug” 
> without
> it.
 
 #1 has been my preference for a while as well, at least as a starting
 point.
>>> 
>>> I should point out that with the resyntaxing of existentials to
>>> Any, the idea that Collection's existential doesn't
>>> conform to Collection becomes far less absurd than it was, so maybe this
>>> is not so bad.
>> 
>> I think the problem is more that Any does not conform to
>> a specific value for a type parameter T: Collection
>> 
>> What I mean by this is that `Collection` denotes a type family, a
>> generic parameter `T: Collection` denotes a specific (though
>> unknown) member of that type family and `Any` denotes
>> the type family again, so there is really no point in writing
>> Any IMO.
>> The type family cannot conform to T because T is just one fixed member 
>> of it.
>> It conforms to itself, though, as I can write
>> let c1: Any = …
>> let c2: Any = c1
>> 
>> That’s why I think that we could just drop Any and simply 
>> write Collection.
> 
> Let me expand that a bit:
> 
> Actually all this talk about existentials vs. generics or protocols
> vs. classes has had me confused somewhat and I think there are still
> some misconceptions present on this list sometimes, so I’ll try to
> clear them up:
 
 There are several objectively incorrect statements here, and several
 others with which I disagree.  I was hoping someone else would write
 this for me, but since the post has such a tone of authority I feel I
 must respond.
>>> 
>>> You are right, the tone of my post was not appropriate, for which I
>>> want to apologize sincerely.
>> 
>> My fundamental disagreement is with the content, not the tone.
>> 
>>> I still believe my statements to be valid, though, and will respond to
>>> your arguments inline. Please don't get me wrong, I'm not trying to
>>> have an argument for the argument's sake. All I want is to contribute
>>> maybe a tiny bit to make Swift even better than it already is, by
>>> sharing ideas and thoughts not only from me but from the designs of
>>> other perhaps more obscure programming languages which I happen to
>>> have stumbled upon in the past (often with much delight).
>> 
>> And I want you to know, even though I disagree with what you've written,
>> that I very much appreciate the contribution you're making.
> 
> Thanks! I’m very glad about that!
> 
> 
>> 
> (1) misconception: protocols with associated types are somehow very
> different from generics
> 
> I don’t think they are and I will explain why. The only difference is
> the way the type parameters are bound: generics use explicit parameter
> lists whereas protocols use inheritance. That has some advantages
> (think long parameter lists of generics) and some disadvantages.
> These ways are dual in a notation sense: generic types have to have
> all parameters bound whereas protocols cannot bind any of them.
> The „existential“ notation `Any<>` 

Re: [swift-evolution] [Pitch] Remove type inference for associated types

[L. Mihalkovic via swift-evolution]

Sometimes I get the sense that the pleasure of discussing takes precedence over 
the goal it serves, namely to create a language that will be the most 
attractive it can be within a given complexity budget (meaning a balance 
between the immediate reward of shiny new things and the long term evolvability 
of the compiler). I seem to recall this item coming directly from chris as a 
compiler cleanup task.

> On Jun 25, 2016, at 3:23 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> Hi Austin,
> 
> I’m sorry to say, but this proposal makes me really sad.  I consider 
> associated type inference one of the more elegant aspects of Swift.  It would 
> be very unfortunate to lose it.  
> 
> I am really pleased to see that Dmitri has offered an alternative that looks 
> very reasonable.  I’m hoping the Doug or Chris (or someone else from the core 
> team) can chime in on the feasibility of this alternative.  If it is 
> considered viable and Dmitri isn’t able to write the proposal I would be 
> happy to do so.
> 
> If the alternative isn’t viable and we must proceed with a proposal to remove 
> inference I think there is one crucial thing to consider that isn’t discussed 
> in this proposal: retroactive modeling.  As far as I can tell, this proposal 
> will *prohibit* some types from conforming to some protocols.  Specifically, 
> if a type defines a typealias with a name that matches the name of an 
> associatedtype in a protocol it would not be possible to retroactively model 
> that protocol.  Because of the name conflict an associatedtype declaration 
> would not be allowed and the existing typealias would not meet the 
> requirement.  Consider this example:
> 
> // Module A
> public struct S {
> public typealias Foo = Int
> }
> 
> // Module B
> public protocol P {
> associatedtype Foo
> }
> 
> // Module C
> import A
> import B
> 
> // compiler error: `S` does not meet the `Foo` associatedtype requirement
> extension S : P {
> // compiler error: cannot define associatedtype `Foo` for `S` which 
> already declares typealias `Foo`
> associatedtype Foo = String
> }
> 
> I cannot support any proposal that breaks retroactive modeling in this way.
> 
> Another item that is not mentioned in this proposal is that typealias is not 
> the only way to meet an associatedtype requirement in the language today.  
> For example, this code is legal:
> 
> protocol Foo {
> associatedtype Bar
> }
> struct S : Foo {
> struct Bar {}
> }
> 
> If we *must* drop inference I prefer the alternative of just doing that: 
> dropping inference, but otherwise leaving things alone.  All associated type 
> requirements would need to be explicitly satisfied using one of the 
> mechanisms that is currently valid for satisfying a non-inferred associated 
> type requirement.  The ability to satisfy these requirements in a variety of 
> ways is a *benefit* that provides valuable flexibility.
> 
> I agree that something should look for a good solution to the subclass 
> typealias issue, but I don’t think this is it.  Ideally we would find a 
> solution that works well in the presence of retroactive modeling making code 
> such as the following valid:
> 
> // module A
> protocol P1 {
> associatedtype Foo
> 
>@infers(Foo)
> var foo: Foo { get }
> }
> // module B
> protocol P2 {
> associatedtype Foo
> 
> @infers(Foo)
> func bar() -> Foo
> }
> 
> // module C
> class Base {
> let foo: String = "foo"
> }
> class Derived : Base {
> func bar() -> Int { return 42 }
> }
> 
> // module D
> import A
> import B
> import C
> import D
> extension Base : P1 {}
> extension Derived : P2 {}
> 
> We don’t always control the protocol or type definitions we want to make work 
> together.  The ability to make code that “should work together” actually do 
> so with minimal fuss is one of the great things about Swift.  Any time we 
> interfere with retroactive modeling we increase the need for boilerplate 
> adapter types, etc.
> 
> One detail appears to be implied by the proposal but isn’t explicitly stated. 
>  Specifically, it looks like the intent is that other than only being valid 
> when used to meet a protocol requirement, associatedtype otherwise works like 
> a typealias.  It would be good to have this behavior clarified if the 
> proposal moves forward.
> 
> -Matthew
> 
> 
> 
>> On Jun 25, 2016, at 12:50 AM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> Hello all,
>> 
>> Per Chris Lattner's list of open Swift 3 design topics 
>> (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369), I've put 
>> together a proposal for removing type inference for associated types.
>> 
>> It can be found here: 
>> https://github.com/austinzheng/swift-evolution/blob/az-assoctypeinf/proposals/-remove-assoctype-inference.md
>> 
>> Thoughts, criticism, and feedback welcome. There are at least two slightly 
>> different designs in the proposal, and 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

> On Jun 25, 2016, at 9:00 AM, L. Mihalkovic  
> wrote:
> 
> Inline
> Regards
> (From mobile)
> 
>> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>>  ]
>>> 
>>> I’ve gone on record before as against this syntax, although when I set out 
>>> earlier today to record my usual rebuttal I found that it really was mostly 
>>> a matter of taste. Yes, this looks weird to me:
>>> 
>>> let callback: (Data) -> NSCoding & NSCopying
>>> 
>>> but I’m sure the infix ‘->’ for functions looked weird to everyone the 
>>> first time they saw it as well, and it really is pretty clear in argument 
>>> position.
>> 
>> We could conceivably bracket the 'where' constraints somewhere. It's nice 
>> not to have to punish the common case syntax. In my personal ideal vision of 
>> the world, I'd like to see us support opening existentials via 
>> path-dependent types (e.g., let a: Collection; let element: a.Element). If 
>> we support them in decl-level 'where' clauses, we provide a nice, clean 
>> syntax for complex generic relationships that doesn't require angle brackets 
>> or per-existential where clauses at all, something like:
>> 
>>   func intersect(a: Collection, b: Collection) -> Collection
>>   where a.Element == b.Element, b.Element == return.Element {
>>   }
>> 
>> which doesn't completely define away the need for 'where' as part of 
>> existential types, but would shrink it quite a bit.
> 
> For some reason it had not clicked until your 'path dependent type' reference 
> how reminicent of (U+00B7) this is. I watched nada's 2014 presentation 
> again... but then it means intersection types would add a lot... you guys 
> seem ok to add P now, so why not take that opportunity to allow P|Q at the 
> same time. Does it also mean that you might consider at some point expanding 
> 'assoctype U'  into:  T where <:U , :>U  opening the door to lower/higher 
> type bounds?

My point was that the dots (pun intended) are starting to connect and I think 
it is a neat path to follow. Strike union type as the first use case is already 
addressed, and it would no matter what be a larger additive. I would love to 
see a future with type bounds, and although the implementation would be a 
massive delta, the syntax change would be very minimal. I will play more with 
my little syntactic exercise to see what a grammar might look like following 
your train of thoughts.

https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051

>> 
>> -Joe
>> 
>>> However, I did remember one issue, which was brought up on the previous 
>>> mega-thread: if we do want to generalize protocol values, we’re going to 
>>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>>> really don’t want to force people to use a typealias to spell such a type, 
>>> but at the same time I want that where clause to be clearly attached to the 
>>> type. (As brought up before the return position of a function is currently 
>>> ambiguous with SE-0081.)
>>> 
>>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>>> against the proposed syntax.
>>> 
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

Inline
Regards
(From mobile)

> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> [Proposal: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>  ]
>> 
>> I’ve gone on record before as against this syntax, although when I set out 
>> earlier today to record my usual rebuttal I found that it really was mostly 
>> a matter of taste. Yes, this looks weird to me:
>> 
>> let callback: (Data) -> NSCoding & NSCopying
>> 
>> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
>> time they saw it as well, and it really is pretty clear in argument position.
> 
> We could conceivably bracket the 'where' constraints somewhere. It's nice not 
> to have to punish the common case syntax. In my personal ideal vision of the 
> world, I'd like to see us support opening existentials via path-dependent 
> types (e.g., let a: Collection; let element: a.Element). If we support them 
> in decl-level 'where' clauses, we provide a nice, clean syntax for complex 
> generic relationships that doesn't require angle brackets or per-existential 
> where clauses at all, something like:
> 
>func intersect(a: Collection, b: Collection) -> Collection
>where a.Element == b.Element, b.Element == return.Element {
>}
> 
> which doesn't completely define away the need for 'where' as part of 
> existential types, but would shrink it quite a bit.

For some reason it had not clicked until your 'path dependent type' reference 
how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... 
but then it means intersection types would add a lot... you guys seem ok to add 
P now, so why not take that opportunity to allow P|Q at the same time. Does 
it also mean that you might consider at some point expanding 'assoctype U'  
into:  T where <:U , :>U  opening the door to lower/higher type bounds?


> 
> -Joe
> 
>> However, I did remember one issue, which was brought up on the previous 
>> mega-thread: if we do want to generalize protocol values, we’re going to 
>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>> really don’t want to force people to use a typealias to spell such a type, 
>> but at the same time I want that where clause to be clearly attached to the 
>> type. (As brought up before the return position of a function is currently 
>> ambiguous with SE-0081.)
>> 
>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>> against the proposed syntax.
>> 
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] UnsafeRawPointer API

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 7:43 PM, Andrew Trick  wrote:
> 
> 
>> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic  
>> wrote:
>> 
>> Very cool...
>> 
>> Couple thoughts
>> 
>> UnsafeMutableRawPointer:
>> func store(, WITH: T)
>> does not flow very well
>> Fill:with: seems nicer or write(, from:T) which means changing 'load' into 
>> 'read'
>> func read(_ : T.Type) -> T
>> func write(_: T.T.Type, from: T) (write even match the method doc)
> 
> Yes but...
> 
> - I was parrotting the current initialize(_: T.Type, with: T) style.
> 
> - I was trying to establish consistency that `from` is used to copy from a 
> pointer which points to a range of elements.
> 
> - Doesn't `fill` imply assigning a range of elements? That would make sense 
> for `storeRaw(contiguous:)` but not the others.
> 
> - `store` by itself may imply assignment. Any previous value will not be 
> destroyed (we don't even know its type). The user needs to be aware of this, 
> at the expense of awkward naming. Safety is more important than convenience 
> here. Hence we need `storeRaw` or `storeBits`. There is a deliberate 
> assymetry between store and load because `load` will initialize its returned 
> value. `store` will not initialize the stored value. `initialize` should be 
> used for that.
> 
> - `writeRaw` sounds a little weird. `writeBits` sounds better.

all makes sense.

>> UnsafeRawPointer.toType():
>> Should it nit be something like typed(as:) instead
> 
> I like "typed(as:)" better than toType(_). I'm debating whether it should be:
> "unsafeCast(toType:)". It's a clarity/safety vs. verbosity tradeoff.

I like the watch-what-you-wish-for warning of unsafeCast.

I think it was really brilliant to introduce the extra step... basically echos 
the alloc/init dichotomy of objc, so it should feel familiar to people with 
this bkgnd

> -Andy
> 
>> Regards
>> LM
>> (From mobile)
>> 
>>> On Jun 24, 2016, at 3:40 AM, Andrew Trick via swift-evolution 
>>>  wrote:
>>> 
>>> I sent two RFC's for this proposal over the past couple months (see Early 
>>> swift-evolution threads). High-level feedback was fairly light. This 
>>> version is a final draft, as I expect it to go through the review process 
>>> next week. There is a lot more explanation and detail in this proposal now, 
>>> and the memory model has been simplified and clarified.
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md
>>> 
>>> If you have opinions or suggestions on API syntax, please make yourself 
>>> heard. You can jump straight to the naming discussion here:
>>> 
>>> https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/-unsaferawpointer.md#variations-under-consideration
>>> 
>>> Of particular interest may be the API names for:
>>> 
>>> - Memory allocation/deallocation: fairly fundamental to the language.
>>> 
>>> - Unsafe casting from raw pointers to typed pointers. This is going to 
>>> impact a lot of code that needs C interoperability.
>>> 
>>> Keep in mind that we will make additive API improvements later for 
>>> convenience. We want the fundamentals to be clear, explicit, and reasonably 
>>> safe.
>>> 
>>> -Andy
>>> 
>>> 
>>> ___
>>> 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] [Returned for revision] SE-0077: Improved operator declarations

[L Mihalkovic via swift-evolution]

Swift is all about values and protocols, so I was thinking about smthg like 
this:

enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
casedefaultGroup(OperatorAssociativity)
indirect case strongerThan(OperatorAssociativity,PrecedenceGroup)
indirect case weakerThan(OperatorAssociativity,PrecedenceGroup)
indirect case between(OperatorAssociativity, strongerThan: PrecedenceGroup, 
weakerThan: PrecedenceGroup)
}

let Additive: PrecedenceGroup = .defaultGroup(.left)
let Multiplicative: PrecedenceGroup = .strongerThan(.left, Additive)
let Exponentiative: PrecedenceGroup = .strongerThan(.left, Multiplicative)
let SomeOtherGroup: PrecedenceGroup = .between(.right, strongerThan: 
Multiplicative, weakerThan: Exponentiative)


standard Swift, which makes it easier to reflect when the api gets created in 
4.0

Regards
LM
(From mobile)


> On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> L. Mihalkovic via swift-evolution <swift-evolution@...> writes:
> 
>>> Could you please explain what you mean by "meta-circular syntax for 
> the 
>>> precedence group definitions"? An example?
>> =define it using existing swift constructs rather than by extending 
> swift with new kwd looks like grp
>> matches a struct. 
> 
> I still don't fully understand without an example :(
> If you mean something like this:
> 
> protocol PrecedenceGroup_Additive {
>associatedtype StrongerThan_Comparative
>associatedtype WeakerThan_Multiplicative
> }
> 
> Then this is just ugly.
> 
> ___
> 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-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 6:04 PM, Jordan Rose  wrote:
> 
> 
>> On Jun 23, 2016, at 22:20, L. Mihalkovic  
>> wrote:
>> 
>> 
>> Regards
>> LM
>> (From mobile)
>> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>>> [Proposal: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>>  ]
>>> 
>>> I’ve gone on record before as against this syntax, although when I set out 
>>> earlier today to record my usual rebuttal I found that it really was mostly 
>>> a matter of taste. Yes, this looks weird to me:
>>> 
>>> let callback: (Data) -> NSCoding & NSCopying
>>> 
>>> but I’m sure the infix ‘->’ for functions looked weird to everyone the 
>>> first time they saw it as well, and it really is pretty clear in argument 
>>> position.
>>> 
>>> However, I did remember one issue, which was brought up on the previous 
>>> mega-thread: if we do want to generalize protocol values, we’re going to 
>>> want something that’s essentially “a type with a ‘where’ clauses in it”. I 
>>> really don’t want to force people to use a typealias to spell such a type, 
>>> but at the same time I want that where clause to be clearly attached to the 
>>> type. (As brought up before the return position of a function is currently 
>>> ambiguous with SE-0081.)
>>> 
>>> Despite the lightweightedness and the well-prepared proposal by Adrian and 
>>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
>>> against the proposed syntax.
>> 
>> This is another way to generalize P compositions that opens another way to 
>> specify WHERE
>> 
>> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051
> 
> Thanks for bringing this up. I know one reason we’ve avoided syntax like this 
> in the past is the potential for static subscripts, but of course that’s just 
> one of many future concerns.
> 
> Jordan

Thank you for reading.

Originally i wanted to make "[" and "]" be CONSTRAINT_BEGIN and CONSTRAINT_END 
respectively to signify that what mattered was the overall structure and how it 
degenerated into this syntax when the composition is not applied to a concrete 
type (i.e. naked P), as well as show that this gave a formal definition to 
Any: a zero term composition that is not limited to a single concrete type, 
otherwise spelled "_ CONSTRAINT_BEGIN CONSTRAINT_END"

Anyhow, it was an interesting mental exercise.

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

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

[L. Mihalkovic via swift-evolution]

Although i understand the intention, there are existing designs in other 
languages offering proven better alternatives. So i would not leave thinking 
that a compelling case for 'Never' has been made.

> On Jun 24, 2016, at 6:01 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0102-
> noreturn-bottom-type.md
> 
> I can think of at least one example of using Never.
> Suppose Stream protocol that returns a value at the end:
> 
> protocol Stream {
>associatedtype Element
>associatedtype Result
> 
>mutable func next() -> Either
> }
> 
> Result can be used for information why the stream has stopped.
> Calling next() after it returns Result is undefined behaviour.
> 
> You can easily see that Iterator is a special case of Stream
> with Result = ().
> 
> Algorithms on IteratorWithResult should not drop the result:
> 
> func forEach(stream: inout S,
>block: (S.Element) -> ())
>-> S.Result
>where S: Stream
> 
> We can split our Stream nicely:
> 
> func split(stream: inout S,
>  take: Int)
>  -> TakePrefixStream
>  where S: Stream
> 
> TakePrefixStream.Result is also a Stream, so to process two parts of 
> stream differently, we do:
> 
> split(s, take: 10).forEach(calledOnFirstTen).forEach(calledOnOthers)
> 
> In the same spirit, we can split a stream into 3 or N parts.
> Note that split itself does not take any elements from the Stream,
> everything is lazy.
> 
> You've already noticed where Never has its place.
> If a stream is infinite, we use Result = Never.
> 
> ___
> 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] Fw: Re: [Proposal Draft] Literal Syntax Protocols

[L. Mihalkovic via swift-evolution]

I find these 'stay-off-my-property' _ rather sub-par in a modern language 
(everything was different for c 40years ago). I find it rather sad to think 
that we r about to commit to using that pattern for another 30 years. If the 
demark between stdlib and compiler was cleaned up, it would even open the door 
to a clean way to make some embedded stdlib versions in the future
Regards
LM
(From mobile)

> On Jun 24, 2016, at 5:22 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware of that fact, but all types with underscore even in the stdlib 
> telling me to keep my hands of them, because something might happen to them.
> 
> As an example we have _Strideable protocol which is visible by its name, but 
> its declaration isn’t visible at all:
> 
> // FIXME(ABI)(compiler limitation): Remove `_Strideable`.
> // WORKAROUND rdar://25214598 - should be:
> // protocol Strideable : Comparable {...}
> 
> % for Self in ['_Strideable', 'Strideable']:
> From Stride.swift.gyb
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 24. Juni 2016 um 17:09:53, Matthew Johnson (matt...@anandabits.com) 
> schrieb:
> 
>> The underscore is used in the same way it is used elsewhere in the standard 
>> library.  The protocols must be public because they need to be visible to 
>> user code in order for the design to work correctly.  However, they are 
>> considered implementation details that users really shouldn’t know about.  
>> This pattern is well established in the standard library.
> 
> ___
> 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] Fwd: [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

More smthg like this:

protocol PrecedGrpType{}
enum OperatorAssociativity { case left, right }
enum PrecedenceGroup {
casedefaultGroup(OperatorAssociativity)
indirect casestrongerThan(OperatorAssociativity,PrecedenceGroup)
indirect caseweakerThan(OperatorAssociativity,PrecedenceGroup)
}

let Additive: PrecedenceGroup = .defaultGroup(.left)
let Multiplicative: PrecedenceGroup = .strongerThan(.left, Additive)
let Exponentiative: PrecedenceGroup = .strongerThan(.left, Multiplicative)

standard Swift, which makes it easier to reflect when the api gets created in 40

Regards
LM
(From mobile)


>> On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> L. Mihalkovic via swift-evolution <swift-evolution@...> writes:
>> 
>>>> Could you please explain what you mean by "meta-circular syntax for
>> the 
>>>> precedence group definitions"? An example?
>>> =define it using existing swift constructs rather than by extending
>> swift with new kwd looks like grp
>>> matches a struct.
>> 
>> I still don't fully understand without an example :(
>> If you mean something like this:
>> 
>> protocol PrecedenceGroup_Additive {
>>associatedtype StrongerThan_Comparative
>>associatedtype WeakerThan_Multiplicative
>> }
>> 
>> Then this is just ugly.
>> 
>> ___
>> 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] Shorthand unwrap proposal

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 24, 2016, at 2:50 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> Yes, this is a bit different. There was a discussion about a month ago 
> (http://thread.gmane.org/gmane.comp.lang.swift.evolution/17142) which had a 
> few good ideas how to deal with the following pattern:
> 
> if let x = x { // do something with x }
> guard let x = x { return }
> 

For my own education i built

if let! x {
// x is shadowed
}


> which is shadowing the original optional value. The suggestion was:
> 
> if let x! { // within this block, x is no longer optional }
> 
> guard let x! { return }
> // Now x is no longer an optional.
> 
> Generally, it re-used the same variable name to safe-unwrap the optional. In 
> your particular example:
> 
> let i: Int? = nil
> if let i! {
>   let y = i.toIntMax()
>   /// ...
> }
> 
> I am aware of the .map (or flatMap) on the optional, however, the guard 
> statement in particular seems like an improvement.
> 
> There are many language constructs in Swift that can be expressed using other 
> constructs - you can go all the way down and say that you really don't need 
> anything other than if and goto.
> 
> The question is whether such a syntax sugar is something that would be help 
> one write safer code and if it's something people would use.
> 
> 
>> On Jun 23, 2016, at 9:32 PM, David Sweeris  wrote:
>> 
>> Dmitri pointed out a few posts ago that Swift already has this.
>> let opInt: Int? = nil
>> opInt.map {$0.toIntMax()} //Evaluates to nil
>> 
>> Are you talking about something different?
>> 
>> - Dave Sweeris
>> 
>>> On Jun 23, 2016, at 2:04 PM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> 
>>> Sure, the exact syntax is a matter of discussion, I just wasn't that much 
>>> of favor of the very short
>>> 
>>> doSomething(with: myOptional?)
>>> 
>>> - it looks like a great idea, making the code really short
>>> - on the other hand the question mark is next to the variable, but the 
>>> method's execution is optional - in that sense something like 
>>> doSomething(?: myOptional)(with: myOptional) makes more sense, declaring 
>>> explicitely what optionals does the execution depend on.
>>> - nevertheless, in the interest of clarity and readability of the code, I'm 
>>> still in favor of the original proposal, which requires you to either use 
>>> if or guard.
>>> 
 On Jun 23, 2016, at 8:57 PM, Tim Vermeulen  wrote:
 
 But ! still suggests force unwrapping, while ? suggests safe unwrapping. 
 Why not use a question mark?
 
> It was in the previous proposal and suggested that you are not trying to 
> shadow the previous variable, but trying to unwrap it - and it acts as 
> unwrapped from there on.
> 
> 
>> On Jun 23, 2016, at 8:52 PM, Tim Vermeulenwrote:
>> 
>> Why with the exclamation mark? It suggests you’re force unwrapping 
>> something.
>> 
 On Jun 23, 2016, at 8:45 PM, Tim Vermeulen via 
 swift-evolutionwrote:
 
 I would love to be able to do something like
 
 doSomething(with: myOptional?)
>>> This actually looks good to me, though if I were a newcomer to the 
>>> language, it would be really cryptic.
>>> 
>>> In case the function returned any value, it could become an optional, 
>>> just like with try?...
>>> 
>>> I still, however, prefer the original proposal of if let myOptional! { 
>>> doSomething(myOptional) }...
>>> 
 
 which would be equivalent to
 
 if let myValue = myOptional {
 doSomething(with: myValue)
 }
 
 But it’s been discussed here before, and I don’t think people were 
 very enthusiastic about it.
 
> I was wondering if people would be open to adding an unwrap method to 
> the Optional type,I already have a method like this which shortens 
> code for me.
> 
> So this:
> 
> let myReallyLongOptionalName: String? = "Hey"
> 
> if let string = myReallyLongOptionalName {
> doSomethingWith(string)
> }
> 
> Could become"
> 
> let myReallyLongOptionalName: String? = "Hey"
> 
> myReallyLongOptionalName.unwrap {
> doSomethingWith($0)
> }
> 
> The block would only be fired if myReallyLongOptionalName has a value.
> 
> 
> ___
> 
> 
> James⎥Head of Trolls
> 
> 
> ja...@supmenow.com(mailto:ja...@supmenow.com)⎥supmenow.com(http://supmenow.com)
> 
> 
> Sup
> 
> 
> Runway East
> 
> 
> 10 Finsbury Square
> 
> 
> 

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

[L. Mihalkovic via swift-evolution]

> On Jun 24, 2016, at 11:25 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I’ve never quite understood why people are so strict about keeping to this?

especially considering how many who do have never seen a vt100 terminal

> 
>> On 24 Jun 2016, at 4:04 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Not a practitioner of 80-character line limits, I take it?
> 
> ___
> 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-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)
> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>  ]
> 
> I’ve gone on record before as against this syntax, although when I set out 
> earlier today to record my usual rebuttal I found that it really was mostly a 
> matter of taste. Yes, this looks weird to me:
> 
> let callback: (Data) -> NSCoding & NSCopying
> 
> but I’m sure the infix ‘->’ for functions looked weird to everyone the first 
> time they saw it as well, and it really is pretty clear in argument position.
> 
> However, I did remember one issue, which was brought up on the previous 
> mega-thread: if we do want to generalize protocol values, we’re going to want 
> something that’s essentially “a type with a ‘where’ clauses in it”. I really 
> don’t want to force people to use a typealias to spell such a type, but at 
> the same time I want that where clause to be clearly attached to the type. 
> (As brought up before the return position of a function is currently 
> ambiguous with SE-0081.)
> 
> Despite the lightweightedness and the well-prepared proposal by Adrian and 
> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance 
> against the proposed syntax.

This is another way to generalize P compositions that opens another way to 
specify WHERE

https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051

> 
> 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] [Pitch] Make the formal type of 'self' consistent in class methods

[L. Mihalkovic via swift-evolution]

Quick (semi) related question: any particular reason for .Type to be a 
contextual kwd rather than defined on a protocol? (No concrete def for 
metatypes?)
Regards
LM
(From mobile)

> On Jun 23, 2016, at 11:02 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov  wrote:
>>> 
>>> 
 On Jun 23, 2016, at 1:46 PM, Andrew Trick  wrote:
 
 
 On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution 
  wrote:
 
 The proposal is to change the type of self to always be Self, which can be 
 thought of as a special generic type parameter bound to the dynamic type 
 of the instance.
>>> 
>>> We’re currently specializing functions that take `self` as an argument. I 
>>> don’t think that will be possible after your proposed change.
>>> 
>>> - Andy
>> 
>> I’m not sure what that means. Do you currently punt on certain optimizations 
>> if a method returns ‘Self’?
>> 
>> It should be possible to keep the reified type information around, by 
>> passing in a metatype or something for example. Can you give a concrete code 
>> snippet demonstrating the optimization and how this change would inhibit it?
> 
> We bail out of generic specialization, inlining, and function signature 
> specialization when a type substitution contains dynamic self. 
> (hasDynamicSelfTypes). So, yes we currently almost entirely punt on 
> optimization for methods that return Self.
> 
> I don’t have an interesting case to point out. You can look into any trivial 
> example:
> 
> func foo(_: T) {}
> 
> func method() {
>   foo(self)
> }
> 
> -Andy
> 
> ___
> 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] [Returned for revision] SE-0077: Improved operator declarations

[L. Mihalkovic via swift-evolution]

Inline
Regards
(From mobile)
> On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> L. Mihalkovic via swift-evolution <swift-evolution@...> writes:
> 
>> Has a meta-circular syntax been considered for the precedence group
> definitions? Aside from limiting the
>> proliferation of new keywords, it would also make them discoverable by
> reflection when the api gets added
>> in 4.0. My apologies if it was already discarded.
>> Regards
>> LM
> 
> Could you please explain what you mean by "meta-circular syntax for the 
> precedence group definitions"? An example?
=define it using existing swift constructs rather than by extending swift with 
new kwd looks like grp matches a struct. 
> ___
> 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