Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

[Riley Testut via swift-evolution]

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution 
>  wrote:


> What is the use-case for a type conforming to this protocol but returning 
> nil?  If there is a use case for that, why not have such an implementation 
> return “self” instead?

I assumed it could be used if a type’s playground representation was variable. 
For instance:

enum MyUnion
{
case string(String)
case image(UIImage)
case none
}

In its implementation of CustomPlaygroundRepresentable, it could return a 
string if case string, an image if case image, or return nil if case none to 
just do whatever is the default for enum values. 

Admittedly the above is a very contrived example, but I do think it is 
important to allow types to opt-out.

> On Jan 9, 2018, at 10:02 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution 
>>  wrote:
>> Good afternoon,
> 
> Hi Connor,
> 
> Huge +1 for this proposal, I’m thrilled you’re cleaning this up.  Couple of 
> detail questions:
> 
>> Detailed design
>> 
>> To provide a more flexible API, we propose deprecating and ultimately 
>> removing the PlaygroundQuickLook enum and CustomPlaygroundQuickLookable 
>> protocol in favor of a simpler design. Instead, we propose introducing a 
>> protocol which just provides the ability to return an Any (or nil) that 
>> serves as a stand-in for the instance being logged:
>> 
> 
> What is the use-case for a type conforming to this protocol but returning 
> nil?  If there is a use case for that, why not have such an implementation 
> return “self” instead?
> 
> In short, can we change playgroundRepresentation to return Any instead of 
> Any?.  Among other things, doing so could ease the case of playground 
> formatting Optional itself, which should presumably get a conditional 
> conformance to this.  :-)
> 
> 
>> /// Implementors of `CustomPlaygroundRepresentable` may return a value of 
>> one of
>> /// the above types to also receive a specialized log representation.
>> /// Implementors may also return any other type, and playground logging will
>> /// generated structured logging for the returned value.
>> public protocol CustomPlaygroundRepresentable {
> On the naming bikeshed, the closest analog to this feature is 
> CustomStringConvertible, which is used when a type wants to customize the 
> default conversion to string.  As such, have you considered 
> CustomPlaygroundConvertible for consistency with it?
> 
> The only prior art for the word “Representable” in the standard library is 
> RawRepresentable, which is quite a different concept.
> 
>>   /// Returns the custom playground representation for this instance, or nil 
>> if
>>   /// the default representation should be used.
>>   ///
>>   /// If this type has value semantics, the instance returned should be
>>   /// unaffected by subsequent mutations if possible.
>>   var playgroundRepresentation: Any? { get }
> Again to align with CustomStringConvertible which has a ‘description’ member, 
> it might make sense to name this member “playgroundDescription”.
> 
> Thank you again for pushing this forward, this will be much cleaner!
> 
> -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-0194: Derived Collection of Enum Cases

[Riley Testut via swift-evolution]

I’m overall +1, but I’m curious: would you be able to conform an enum from 
another module to ValueEnumerable via an extension, and still have the compiler 
generate the protocol requirements for you? I can imagine that the client of a 
framework with an enum may have a valid use for iterating over all values that 
the author didn’t foresee, and I would very much like the client to be able to 
opt-in to the compiler code generation.

(Personally, I’d prefer that all simple enums automatically conform to the 
protocol and have automatic implementations, since I don’t really see a 
downside to this that exists for some other compiler-magic protocols like 
Codable)

> On Jan 9, 2018, at 8:45 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
>> On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution 
>>  wrote:
>> Hello Swift community,
>> 
>> The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs 
>> through January 11, 2018. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.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. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine 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?
> Big +1. I've been looking forward to something like this for a long time.
> 
> I'm extremely happy with the API chosen here. ValueEnumerable and allValues 
> are absolutely the correct names, because the protocol is not *restricted* to 
> enums, it is merely *synthesized automatically* for enums. That's a very 
> important distinction. Someone could provide their own conformance to 
> ValueEnumerable and use it in generic algorithms and have everything work as 
> expected.
> 
> In a perfect world I would argue that the associated type of allValues should 
> be a Sequence instead of a Collection as this would allow it to be extended 
> to infinite sequences (i.e., cases with associated values that are deeply 
> ValueEnumerable), but I'll admit that I've never come up with a compelling 
> use case for this beyond obscure combinatorial algorithms. Since getting the 
> count of values is important to many users, Collection is a reasonable 
> compromise and I don't have any objections.
>  
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes. It's a frequently requested feature and has utility both in UI-driven 
> logic (table view sections based on an enum) and other algorithms.
> 
>  
>> Does this proposal fit well with the feel and direction of Swift?
> Yes. The API design fits right into other stdlib concepts, and the conditions 
> for synthesis align with the synthesis of other synthesized protocols.
> 
>  
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> Just Java's values() function that is present on all enums. The functionality 
> provided here is what I would expect, similar to other languages.
> 
>  
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> An in-depth read and I was heavily involved in some of the earlier discussion 
> threads.
> 
>  
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Riley Testut via swift-evolution]

Actually, from the other email thread about this same topic (thank god forums 
are almost here), I see the proposed syntax “final switch” for what I referred 
to as “switch!”, which I prefer.

> On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> -1.
> 
> I agree this is a problem, but I think this is the wrong solution. I think 
> the solution should be on the client side, not on the framework author’s side.
> 
> I would be fine if enums from imported modules are non-exhaustive, as long as 
> I can choose to treat them as exhaustive if I want to. And in that case, if a 
> new case is introduced, I think a fatal error is a reasonable result.
> 
> The proposed “switch!” command would do just this, and I think that is the 
> better answer for this. Adding an @exhaustive attribute doesn’t actually 
> prevent someone from adding a case anyway, which I think is a big (and not 
> really solvable) issue 路‍♂️
> 
> I know much has been said about this, but it’s just my 2c.
> 
>> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> 
>>> The proposal is available here:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> What is your evaluation of the proposal?
>>> 
>> 
>> -1
>> 
>> I would much prefer the solution proposed by Andrew Bennett in another 
>> thread which solves all problems very nicely including the testability of 
>> future cases by giving them a placeholder name:
>> 
>> From Andrew’s mail:
>>> public enum HomeworkExcuse {
>>>   case eatenByPet
>>>   case thoughtItWasDueNextWeek
>>>   fallback unknown // NEW
>>> }
>>> 
>>> Then I believe you would be able to have an exhaustive switch like this:
>>> 
>>> switch thing {
>>>   case eatenByPet: break
>>>   case thoughtItWasDueNextWeek: break
>>>   case unknown: break
>>> }
>>> 
>>> Which would still allow compile-time errors if new cases are introduced, 
>>> while providing a concise way to show something is not exhaustible.
>>> 
>>> This would also support existing enums with "unknown" equivalent cases 
>>> would be able to explicitly label those fields as fallback without needing 
>>> to make large code changes.
>>> 
>>> I see no reason why you shouldn't be able to use ".unknown", which should 
>>> still allow this to be testable.
>> 
>> i.e. Andrew’s idea is to introduce a placeholder case instead of marking the 
>> enum as exhaustive/non-exhaustive. This gives the future cases a handle to 
>> be switched on and to be tested against. Very elegant.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> 
>> Yes, but the proposed solution is not as good as it should be, neglecting to 
>> provide compile-time errors if new cases are introduced.
>>> Does this proposal fit well with the feel and direction of Swift?
>>> 
>> No, due to its shortcomings.
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> 
>> None, but see Andrew Bennett’s idea above.
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>>> 
>> Followed most of the discussion and review threads.
>> 
>> -Thorsten
>> ___
>> 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 0192 - Non-Exhaustive Enums

[Riley Testut via swift-evolution]

-1.

I agree this is a problem, but I think this is the wrong solution. I think the 
solution should be on the client side, not on the framework author’s side.

I would be fine if enums from imported modules are non-exhaustive, as long as I 
can choose to treat them as exhaustive if I want to. And in that case, if a new 
case is introduced, I think a fatal error is a reasonable result.

The proposed “switch!” command would do just this, and I think that is the 
better answer for this. Adding an @exhaustive attribute doesn’t actually 
prevent someone from adding a case anyway, which I think is a big (and not 
really solvable) issue 路‍♂️

I know much has been said about this, but it’s just my 2c.

> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
> 
>> The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>> What is your evaluation of the proposal?
>> 
> 
> -1
> 
> I would much prefer the solution proposed by Andrew Bennett in another thread 
> which solves all problems very nicely including the testability of future 
> cases by giving them a placeholder name:
> 
> From Andrew’s mail:
>> public enum HomeworkExcuse {
>>   case eatenByPet
>>   case thoughtItWasDueNextWeek
>>   fallback unknown // NEW
>> }
>> 
>> Then I believe you would be able to have an exhaustive switch like this:
>> 
>> switch thing {
>>   case eatenByPet: break
>>   case thoughtItWasDueNextWeek: break
>>   case unknown: break
>> }
>> 
>> Which would still allow compile-time errors if new cases are introduced, 
>> while providing a concise way to show something is not exhaustible.
>> 
>> This would also support existing enums with "unknown" equivalent cases would 
>> be able to explicitly label those fields as fallback without needing to make 
>> large code changes.
>> 
>> I see no reason why you shouldn't be able to use ".unknown", which should 
>> still allow this to be testable.
> 
> i.e. Andrew’s idea is to introduce a placeholder case instead of marking the 
> enum as exhaustive/non-exhaustive. This gives the future cases a handle to be 
> switched on and to be tested against. Very elegant.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> 
> Yes, but the proposed solution is not as good as it should be, neglecting to 
> provide compile-time errors if new cases are introduced.
>> Does this proposal fit well with the feel and direction of Swift?
>> 
> No, due to its shortcomings.
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> 
> None, but see Andrew Bennett’s idea above.
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> 
> Followed most of the discussion and review threads.
> 
> -Thorsten
> ___
> 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] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Riley Testut via swift-evolution]

> On Nov 9, 2017, at 9:01 AM, Philippe Hausler  wrote:
> 
> I have personally filed a few bugs on this; and I definitely consider it a 
> bug that we cannot store Any in generics for objc. There are however some 
> problem areas that might be worth considering while fixing this bug. 
> 
> 1) We need to ensure this does not cause source churn - I would expect swift 
> 4 to be source compatible with swift 5.

Agreed. I'd be surprised if this would cause churn though, since this is 
effectively just loosening a restriction, and all existing use cases would 
still be allowed.

> 
> 2) There are a few cases that might be a bit cagey - you claim NSCache, but 
> would it be surprising that the boxed object having no refs gets purged? How 
> bout NSPointerArray? 

I agree there are certain cases where true reference semantics are important, 
and off the top of my head I can think of two (relatively easy) ways we could 
accommodate this:

1) The Objective-C class declaration explicitly specifies an upper-bound of 
NSObject (or NSObjectProtocol).
2) Add a new keyword (similar to existing __covariant and __contravariant 
keywords) such as __reference (where the final name would of course be 
bike-shedded)

I’m leaning towards an approach similar to 2) since 1) might be confusing to 
newcomers due to it seemingly have no purpose considering the NSObject 
constraint would implicitly there where using the generic class from 
Objective-C code.

I’m not familiar with NSCache’s internals, so I wasn’t aware references play a 
role in whether or not NSCache purges an object. That being said, I don’t think 
it would be surprising if NSCache purged a large Data value under memory 
pressure, as long as it didn’t affect any “copies” I had retrieved and was 
currently using. 

As for NSPointerArray, we’d still need to get Objective-C generics for it first 
 Though assuming that is added, the generic parameter would need to explicitly 
say it requires a reference.

> 3) Since Foundation is likely the most impact here I think it would be useful 
> to audit the results of this before pushing it out; specifically the 
> Foundation internal builds so that we can make sure the things we are working 
> on function correctly.
> 
> Do you have implementations in the works yet? I really think this is 
> important for us to get in (especially before the ABI gets locked down cause 
> it could have impact there…)


No I don’t, but would be open to digging into it and seeing what I could do as 
a proof-of-concept (I just don’t know where I’d start looking to accomplish 
this).___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Riley Testut via swift-evolution]

> On Nov 8, 2017, at 11:51 AM, Joe Groff  wrote:
> 
> In principle it makes sense, but there are implementation challenges we 
> didn't have time to consider. It would be nice to make this happen when we 
> have the time to make it work.

Just out of curiosity, what were some of those implementation challenges? And 
have any of these changed with the evolution of the standard library since then?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Riley Testut via swift-evolution]

Hi Swift-Evolution,

Back when SE-0057 
(https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md)
 was proposed, it included the following passage:

The generic type parameters in Swift will always be class-bound, i.e., the 
generic class will have the requirement T : AnyObject.
This made sense at the time, since Swift <-> Objective-C interoperability was 
only possible with class types (AnyObject). However, several months after 
SE-0057 was accepted, SE-0116 
(https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md)
 was accepted, which allowed for bridging any type to Objective-C, not just 
class types.

This greatly improved interoperability between Swift and Objective-C code, but 
the AnyObject restriction on Objective-C generics remained. This issue is 
especially apparent when using lesser-known Objective-C collection types such 
as NSCache, where it may make sense to store value types or use value types as 
the keys, but the compiler does not allow it.

I propose that this restriction is lifted, and that generic Objective-C 
parameters are no longer restricted to conforming to AnyObject. I’m assuming 
this is not as straightforward as it might seem at first to implement, but I 
think the benefits would make the effort worth it, since this seems like an 
overlooked case and not intentionally kept this way.

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Riley Testut via swift-evolution]

Just as one small data point, I had no idea private extensions still applied 
fileprivate access to all members (I thought that had changed when SE-0169 was 
implemented). I’ve been using private extensions extensively because I thought 
they *did* apply private access to everything, not fileprivate.

Now knowing this isn’t the case, I can only imagine how many other people would 
be tripped up be this (especially people who haven’t followed Swift Evolution). 
I definitely think this inconsistency needs to be fixed.

> On Oct 4, 2017, at 8:48 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> It certainly could break *some* code. But it only breaks code written by an 
> author who wrote ‘private extension’ knowing that ‘fileprivate extension’ was 
> also an option, but still intended it to be shared with the whole file. (If 
> that code was from Swift 2, it would have already been migrated to 
> ‘fileprivate extension’ by the 2->3 migrator.)
> 
> So existing code that says ‘private extension’ was written in a Swift 3 or 4 
> era when ‘fileprivate’ was an option. If the goal was specifically to share 
> it with the whole file, it seems likely that most authors would have used 
> ‘fileprivate extension’ instead of ‘private extension’, as that better 
> communicates the intention. Regardless, though, we could check against the 
> Swift source compatibility test suite to see how widespread that is.
> 
> Regardless, I think this change makes Swift a better language, and I’m in 
> favor of it.
> 
> -BJ
> 
>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
  wrote:
 
> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPad
> 
>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> On 01.10.2017 1:18, Chris Lattner wrote:
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Vladimir, I agree with you on that change, but it’s a separate topic 
> from this one.
> 
> Tony is absolutely correct that this topic has already been 
> discussed. It is a deliberate design decision that public types do 
> not automatically expose members without explicit access modifiers; 
> this has been brought up on this list, and it is clearly not in scope 
> for discussion as no new insight can arise this late in the game. The 
> inconsistency with public extensions was brought up, the proposed 
> solution was to remove modifiers for extensions, but this proposal 
> was rejected. So, the final design is what we have.
 Agreed.  The core team would only consider a refinement or change to 
 access control if there were something actively broken that mattered 
 for ABI stability.
>>> 
>>> So we have to live with *protected* extension inconsistency for very 
>>> long time just because core team don't want to even discuss _this 
>>> particular_ inconsistency(when access level in *private extension* must 
>>> be private, not fileprivate)?
>>> 
>>> Yes, we decided that access level for extension will mean a default and 
>>> top most access level for nested methods, OK. But even in this rule, 
>>> which already differ from access modifiers for types, we have another 
>>> one special case for 'private extension'.
>>> 
>>> Don't you think this is not normal situation and actually there IMO 
>>> can't be any reason to keep this bug-producing inconsistency in Swift? 
>>> (especially given Swift 5 seems like is a last moment to fix this)
>> 
>> I hate to say it but I'm inclined to agree with Vladimir on this. 
>> "private extension" has a useful meaning now distinct from "fileprivate 
>> extension", and it was an oversight that SE-0169 didn't include a fix 
>> here. On this very narrow, very specific access control issue I think it 
>> would still be worth discussing; like Xiaodi said it's not related to 
>> James' original thread-starter.
> 
> I agree with this in principle but would not want to see it become a 
> slippery slope back into extremely long access control discussions.
> 
 
 As I've said elsewhere, I too agree with this in principle. I agree with 
 Jordan that the current state of things is justifiable but the alternative 
 would be 

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

 keywords for distinct concepts, unlike 
>>>>>>> Rust which likes to reuse keywords in clever ways; if you’re finding 
>>>>>>> that things are getting confusing with one word meaning two things, 
>>>>>>> that shouldn’t be an invitation to rip out existing syntax but is 
>>>>>>> probably a good sign you shouldn’t be repurposing that keyword.
>>>>>>> 
>>>>>>> 
>>>>>>> On Sun, Jun 11, 2017 at 03:28 Adrian Zubarev via swift-evolution 
>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>> Yeah, well I messed up my proposal from last year about removing the 
>>>>>>> access modifier on extensions and wish now I wasn’t that confused back 
>>>>>>> than and made it right.
>>>>>>> 
>>>>>>> The indirect keyword is literally the same story. The docs only says 
>>>>>>> that this is only a shortcut.
>>>>>>> 
>>>>>>> „To enable indirection for all the cases of an enumeration, mark the 
>>>>>>> entire enumeration with the indirect modifier—this is convenient when 
>>>>>>> the enumeration contains many cases that would each need to be marked 
>>>>>>> with the indirect modifier.“
>>>>>>> 
>>>>>>> If you really wish to reuse that keyword here we might need to remove 
>>>>>>> such shortcuts from the language (indirect enum, access modifier on 
>>>>>>> extensions, anything else?).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Adrian Zubarev
>>>>>>> Sent with Airmail
>>>>>>> 
>>>>>>> Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan (g...@gyolchanyan.com 
>>>>>>> <mailto:g...@gyolchanyan.com>) schrieb:
>>>>>>> 
>>>>>>>> I always wondered, why is `indirect` allowed on the `enum` itself? 
>>>>>>>> Wouldn't it make more sense to apply it to individual cases that 
>>>>>>>> recursively refer to the `enum`?
>>>>>>>> This question also applies to access modifiers on extensions. So, what 
>>>>>>>> is it supposed to do? Change the default access modifier from 
>>>>>>>> `internal` to whatever I specify? That's just confusing, reduces 
>>>>>>>> readability and the syntactic gain is marginal at best.
>>>>>>>> If the `indirect` confusion becomes real, I'd suggest getting rid of 
>>>>>>>> `indirect enum` and using `indirect case` instead.
>>>>>>>> 
>>>>>>>>> On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution 
>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>>>>> 
>>>>>>>>> The proposal is looking good to me. :) It will also enable easy 
>>>>>>>>> support for custom views using XIBs in iOS development without 
>>>>>>>>> unnecessary view nesting.
>>>>>>>>> 
>>>>>>>>> For instance the function from this example 
>>>>>>>>> https://stackoverflow.com/a/43123783/4572536 
>>>>>>>>> <https://stackoverflow.com/a/43123783/4572536> could be used directly 
>>>>>>>>> inside an init:
>>>>>>>>> 
>>>>>>>>> class MyView : UIView {
>>>>>>>>>   
>>>>>>>>>   indirect init() {
>>>>>>>>> return MyView.instantiateFromXib()
>>>>>>>>> // Or after SR-0068
>>>>>>>>> return Self.instantiateFromXib()
>>>>>>>>>   }
>>>>>>>>> }
>>>>>>>>> There is still one little thing that bothers me, it might be a little 
>>>>>>>>> bit confusing to have two different meanings of indirect on enums.
>>>>>>>>> 
>>>>>>>>> indirect enum ArithmeticExpression {
>>>>>>>>> case number(Int)
>>>>&

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

 made it right.
>>>>>>>>>>> 
>>>>>>>>>>> The indirect keyword is literally the same story. The docs only 
>>>>>>>>>>> says that this is only a shortcut.
>>>>>>>>>>> 
>>>>>>>>>>> „To enable indirection for all the cases of an enumeration, mark 
>>>>>>>>>>> the entire enumeration with the indirect modifier—this is 
>>>>>>>>>>> convenient when the enumeration contains many cases that would each 
>>>>>>>>>>> need to be marked with the indirect modifier.“
>>>>>>>>>>> 
>>>>>>>>>>> If you really wish to reuse that keyword here we might need to 
>>>>>>>>>>> remove such shortcuts from the language (indirect enum, access 
>>>>>>>>>>> modifier on extensions, anything else?).
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Adrian Zubarev
>>>>>>>>>>> Sent with Airmail
>>>>>>>>>>> 
>>>>>>>>>>> Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan 
>>>>>>>>>>> (g...@gyolchanyan.com) schrieb:
>>>>>>>>>>> 
>>>>>>>>>>>> I always wondered, why is `indirect` allowed on the `enum` itself? 
>>>>>>>>>>>> Wouldn't it make more sense to apply it to individual cases that 
>>>>>>>>>>>> recursively refer to the `enum`?
>>>>>>>>>>>> This question also applies to access modifiers on extensions. So, 
>>>>>>>>>>>> what is it supposed to do? Change the default access modifier from 
>>>>>>>>>>>> `internal` to whatever I specify? That's just confusing, reduces 
>>>>>>>>>>>> readability and the syntactic gain is marginal at best.
>>>>>>>>>>>> If the `indirect` confusion becomes real, I'd suggest getting rid 
>>>>>>>>>>>> of `indirect enum` and using `indirect case` instead.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution 
>>>>>>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The proposal is looking good to me. :) It will also enable easy 
>>>>>>>>>>>>> support for custom views using XIBs in iOS development without 
>>>>>>>>>>>>> unnecessary view nesting.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For instance the function from this example 
>>>>>>>>>>>>> https://stackoverflow.com/a/43123783/4572536 could be used 
>>>>>>>>>>>>> directly inside an init:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> class MyView : UIView {
>>>>>>>>>>>>>   
>>>>>>>>>>>>>   indirect init() {
>>>>>>>>>>>>> return MyView.instantiateFromXib()
>>>>>>>>>>>>> // Or after SR-0068
>>>>>>>>>>>>> return Self.instantiateFromXib()
>>>>>>>>>>>>>   }
>>>>>>>>>>>>> }
>>>>>>>>>>>>> There is still one little thing that bothers me, it might be a 
>>>>>>>>>>>>> little bit confusing to have two different meanings of indirect 
>>>>>>>>>>>>> on enums.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> indirect enum ArithmeticExpression {
>>>>>>>>>>>>> case number(Int)
>>>>>>>>>>>>> case addition(ArithmeticExpression, ArithmeticExpression)
>>>>>>>>>>>>> case mult

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

yntax but is 
>>>>>>>> probably a good sign you shouldn’t be repurposing that keyword.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Sun, Jun 11, 2017 at 03:28 Adrian Zubarev via swift-evolution 
>>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>> Yeah, well I messed up my proposal from last year about removing the 
>>>>>>>>> access modifier on extensions and wish now I wasn’t that confused 
>>>>>>>>> back than and made it right.
>>>>>>>>> 
>>>>>>>>> The indirect keyword is literally the same story. The docs only says 
>>>>>>>>> that this is only a shortcut.
>>>>>>>>> 
>>>>>>>>> „To enable indirection for all the cases of an enumeration, mark the 
>>>>>>>>> entire enumeration with the indirect modifier—this is convenient when 
>>>>>>>>> the enumeration contains many cases that would each need to be marked 
>>>>>>>>> with the indirect modifier.“
>>>>>>>>> 
>>>>>>>>> If you really wish to reuse that keyword here we might need to remove 
>>>>>>>>> such shortcuts from the language (indirect enum, access modifier on 
>>>>>>>>> extensions, anything else?).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Adrian Zubarev
>>>>>>>>> Sent with Airmail
>>>>>>>>> 
>>>>>>>>> Am 11. Juni 2017 um 10:12:38, Gor Gyolchanyan (g...@gyolchanyan.com) 
>>>>>>>>> schrieb:
>>>>>>>>> 
>>>>>>>>>> I always wondered, why is `indirect` allowed on the `enum` itself? 
>>>>>>>>>> Wouldn't it make more sense to apply it to individual cases that 
>>>>>>>>>> recursively refer to the `enum`?
>>>>>>>>>> This question also applies to access modifiers on extensions. So, 
>>>>>>>>>> what is it supposed to do? Change the default access modifier from 
>>>>>>>>>> `internal` to whatever I specify? That's just confusing, reduces 
>>>>>>>>>> readability and the syntactic gain is marginal at best.
>>>>>>>>>> If the `indirect` confusion becomes real, I'd suggest getting rid of 
>>>>>>>>>> `indirect enum` and using `indirect case` instead.
>>>>>>>>>> 
>>>>>>>>>>> On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution 
>>>>>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> The proposal is looking good to me. :) It will also enable easy 
>>>>>>>>>>> support for custom views using XIBs in iOS development without 
>>>>>>>>>>> unnecessary view nesting.
>>>>>>>>>>> 
>>>>>>>>>>> For instance the function from this example 
>>>>>>>>>>> https://stackoverflow.com/a/43123783/4572536 could be used directly 
>>>>>>>>>>> inside an init:
>>>>>>>>>>> 
>>>>>>>>>>> class MyView : UIView {
>>>>>>>>>>>   
>>>>>>>>>>>   indirect init() {
>>>>>>>>>>> return MyView.instantiateFromXib()
>>>>>>>>>>> // Or after SR-0068
>>>>>>>>>>> return Self.instantiateFromXib()
>>>>>>>>>>>   }
>>>>>>>>>>> }
>>>>>>>>>>> There is still one little thing that bothers me, it might be a 
>>>>>>>>>>> little bit confusing to have two different meanings of indirect on 
>>>>>>>>>>> enums.
>>>>>>>>>>> 
>>>>>>>>>>> indirect enum ArithmeticExpression {
>>>>>>>>>>> case number(Int)
>>>>>

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

IIRC I had a discussion with Douglas Gregor about the overriding aspect of 
factory initializers, and the takeaway was that it would just be like 
convenience initializers. Technically, convenience initializers cannot be 
overridden, but a subclass *can* implement a convenience method with the same 
signature as its superclass' convenience method. The only difference is it 
can't call the super initializer. I think this *does* make the most sense, 
because I'm not sure super.init for an indirect initializer makes much sense, 
and if you really wanted to do that, you could just call the initializer 
directly (aka "let superReturnValue = Type()). But happy to change if you feel 
strongly it should be allowed!

I left out the Objective-C/C interoperability aspects because IMO they aren't 
necessary for this proposal. This proposal is specifically limited to adding a 
new indirect initializer to Swift. I could mention that it would be exposed to 
Objective-C just like other initializers, but anything more than that I think 
should be a separate proposal (such as how C/Objective-C initializers would be 
imported).

Also, what parts sound like a personal letter? The motivation + examples are 
motivated by personal experience, and so I wrote them from my perspective 
(similar to other proposals), but the proposed solution + detailed design 
should be straightforward and void of opinions. 

> On Jun 10, 2017, at 5:25 PM, Gor Gyolchanyan  wrote:
> 
> Looks good, but I have a few thoughts on it:
> 
> * I think indirect initializers *shoud* be overridable, but only by other 
> indirect initializers. This will allow subclasses of the factory to expand 
> the factory method by adding new possible instances to return.
> * You did not include the specification of implementation details that I 
> provided as well as C/Objective-C interoperability changes.
> * The proposal is formulated more like a personal opinion, rather then a 
> formal specification. It sounds like a personal letter. I'd recommend writing 
> it similarly as you'd write a wikipedia page.
> 
>> On Jun 11, 2017, at 1:12 AM, Riley Testut  wrote:
>> 
>> Awesome! Updated my proposal to include what I believed to be the relevant 
>> portions of your indirect initializer idea. Let me know if there’s anything 
>> I missed or should change :-)
>> 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>>> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan  wrote:
>>> 
>>> Hi, Riley!
>>> 
>>> I think that's a great idea! We can merge the second part of my proposal 
>>> (the `indirect init`) into your one and refine and consolidate the 
>>> prerequisite proposal (about returning from `init` and possibly in-place 
>>> member initializers) and bunch them up into a proposal cluster (the way 
>>> swift coders did).
>>> Feel free to tear out any chunks from my proposal, while I think about a 
>>> more in-depth rationale about revamping initialization syntax. 
>>> 
 On Jun 10, 2017, at 8:36 PM, Riley Testut  wrote:
 
 Hi Gor 
 
 I’m very much in fan of a unified initialization syntax. I submitted my 
 own proposal for factory initializers a while back, but since it wasn’t a 
 focus of Swift 3 or 4 I haven’t followed up on it recently. In the time 
 since last working on it, I came to my own conclusion that rather than 
 focusing on factory initialization, the overall initialization process 
 should be simplified, which I’m glad to see someone else has realized as 
 well :-)
 
 Here’s my proposal for reference: 
 https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e
  Originally I used the “factory” keyword, but I think your “indirect” 
 keyword may be a better fit (since it has precedent in the language and is 
 not limited to “just” being about factory initialization). To divide your 
 proposal up into smaller pieces for review, maybe we could update my 
 proposal to use your indirect keyword, and then start a separate 
 topic/proposal for the remaining aspects of your proposal? I agree that 
 splitting it into smaller chunks may be better for the process.
 
 Let me know what you think!
 
 Riley
 
 
>> On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution 
>>  wrote:
>> 
>> 
>> This is a very interesting read.
> 
> Thanks you! I tried to make it as clear and detailed as possible.  
> 
>> 
>> We did not discuss the 'indirect' idea at all on this list. Did you come 
>> up with it just now? In any case, my suggestion as to moving forward 
>> would be this:
> I was writing the proposal and was just about to write `factory init`, 
> when it occurred to me: enums already have a keyword that does 

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

Awesome! Updated my proposal to include what I believed to be the relevant 
portions of your indirect initializer idea. Let me know if there’s anything I 
missed or should change :-)

https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

> On Jun 10, 2017, at 12:43 PM, Gor Gyolchanyan  wrote:
> 
> Hi, Riley!
> 
> I think that's a great idea! We can merge the second part of my proposal (the 
> `indirect init`) into your one and refine and consolidate the prerequisite 
> proposal (about returning from `init` and possibly in-place member 
> initializers) and bunch them up into a proposal cluster (the way swift coders 
> did).
> Feel free to tear out any chunks from my proposal, while I think about a more 
> in-depth rationale about revamping initialization syntax. 
> 
>> On Jun 10, 2017, at 8:36 PM, Riley Testut > > wrote:
>> 
>> Hi Gor 
>> 
>> I’m very much in fan of a unified initialization syntax. I submitted my own 
>> proposal for factory initializers a while back, but since it wasn’t a focus 
>> of Swift 3 or 4 I haven’t followed up on it recently. In the time since last 
>> working on it, I came to my own conclusion that rather than focusing on 
>> factory initialization, the overall initialization process should be 
>> simplified, which I’m glad to see someone else has realized as well :-)
>> 
>> Here’s my proposal for reference: 
>> https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e
>>  
>> 
>>  Originally I used the “factory” keyword, but I think your “indirect” 
>> keyword may be a better fit (since it has precedent in the language and is 
>> not limited to “just” being about factory initialization). To divide your 
>> proposal up into smaller pieces for review, maybe we could update my 
>> proposal to use your indirect keyword, and then start a separate 
>> topic/proposal for the remaining aspects of your proposal? I agree that 
>> splitting it into smaller chunks may be better for the process.
>> 
>> Let me know what you think!
>> 
>> Riley
>> 
>> 
>>> On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution 
>>> > wrote:
>>> 
 
 This is a very interesting read.
 
>>> 
>>> Thanks you! I tried to make it as clear and detailed as possible.  
>>> 
 
 We did not discuss the 'indirect' idea at all on this list. Did you come 
 up with it just now? In any case, my suggestion as to moving forward would 
 be this:
 
>>> I was writing the proposal and was just about to write `factory init`, when 
>>> it occurred to me: enums already have a keyword that does something very 
>>> similar. It seemed to me that an initializer that doesn't initialize the 
>>> instance in-place, but returns a completely separate instance from 
>>> somewhere else, is kinda "indirectly" initializing the instance. Plus, the 
>>> already established keyword and its semantic would reduce the learning 
>>> curve for this new feature and separate it from a single specific use case 
>>> (the "factory method" pattern).
>>> 
 
 - Do you feel that both halves of your draft (expanding `return` in 
 initializers, and `indirect` initializers) should absolutely be one 
 proposal, or can they be separated?
 
>>> I think the `return` can be easily implemented first, while opening up an 
>>> opportunity to later implement `indirect init`. The reason why I unified 
>>> them was that the `return` idea on its own has very limited merit and could 
>>> the thought of as a low-priority cosmetic enhancement. I wouldn't want it 
>>> to be viewed that way because the primary purpose of that idea is to enable 
>>> `indirect init` (which Cocoa and Cocoa Touch developers would be very happy 
>>> about). 
>>> 
 
 a) If they can be separated because each half has individual merit, then 
 these ideas may be more likely to succeed as separate proposals, as each 
 can be critiqued fully and judged independently as digestible units.
 
>>> 
>>> Very good point. The challenge is to correctly separate them, without 
>>> losing context in their respective proposals and without bleeding the 
>>> proposals into each other.
>>> 
>>> 
 
>>> 
 b) If you intend to tackle all your ideas all at once, that's going to be 
 a much bigger change--in terms of review effort, likely bikeshedding, and 
 implementation effort. It'll probably be best to solicit initial feedback 
 on this list first about `indirect` initializers, even if just to 
 familiarize the community with the idea, before launching into a pitch of 
 the whole proposal.
 
>>> 
>>> I'd never send a pull request to swift-evolution without thoroughly 
>>> discussing it here. I 

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

[Riley Testut via swift-evolution]

Hi Gor 

I’m very much in fan of a unified initialization syntax. I submitted my own 
proposal for factory initializers a while back, but since it wasn’t a focus of 
Swift 3 or 4 I haven’t followed up on it recently. In the time since last 
working on it, I came to my own conclusion that rather than focusing on factory 
initialization, the overall initialization process should be simplified, which 
I’m glad to see someone else has realized as well :-)

Here’s my proposal for reference: 
https://github.com/apple/swift-evolution/pull/247/commits/58b5a93b322aae998eb40574dee15fe54323de2e
 

 Originally I used the “factory” keyword, but I think your “indirect” keyword 
may be a better fit (since it has precedent in the language and is not limited 
to “just” being about factory initialization). To divide your proposal up into 
smaller pieces for review, maybe we could update my proposal to use your 
indirect keyword, and then start a separate topic/proposal for the remaining 
aspects of your proposal? I agree that splitting it into smaller chunks may be 
better for the process.

Let me know what you think!

Riley


> On Jun 10, 2017, at 3:33 AM, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
>> 
>> This is a very interesting read.
>> 
> 
> Thanks you! I tried to make it as clear and detailed as possible.  
> 
>> 
>> We did not discuss the 'indirect' idea at all on this list. Did you come up 
>> with it just now? In any case, my suggestion as to moving forward would be 
>> this:
>> 
> I was writing the proposal and was just about to write `factory init`, when 
> it occurred to me: enums already have a keyword that does something very 
> similar. It seemed to me that an initializer that doesn't initialize the 
> instance in-place, but returns a completely separate instance from somewhere 
> else, is kinda "indirectly" initializing the instance. Plus, the already 
> established keyword and its semantic would reduce the learning curve for this 
> new feature and separate it from a single specific use case (the "factory 
> method" pattern).
> 
>> 
>> - Do you feel that both halves of your draft (expanding `return` in 
>> initializers, and `indirect` initializers) should absolutely be one 
>> proposal, or can they be separated?
>> 
> I think the `return` can be easily implemented first, while opening up an 
> opportunity to later implement `indirect init`. The reason why I unified them 
> was that the `return` idea on its own has very limited merit and could the 
> thought of as a low-priority cosmetic enhancement. I wouldn't want it to be 
> viewed that way because the primary purpose of that idea is to enable 
> `indirect init` (which Cocoa and Cocoa Touch developers would be very happy 
> about). 
> 
>> 
>> a) If they can be separated because each half has individual merit, then 
>> these ideas may be more likely to succeed as separate proposals, as each can 
>> be critiqued fully and judged independently as digestible units.
>> 
> 
> Very good point. The challenge is to correctly separate them, without losing 
> context in their respective proposals and without bleeding the proposals into 
> each other.
> 
> 
>> 
> 
>> b) If you intend to tackle all your ideas all at once, that's going to be a 
>> much bigger change--in terms of review effort, likely bikeshedding, and 
>> implementation effort. It'll probably be best to solicit initial feedback on 
>> this list first about `indirect` initializers, even if just to familiarize 
>> the community with the idea, before launching into a pitch of the whole 
>> proposal.
>> 
> 
> I'd never send a pull request to swift-evolution without thoroughly 
> discussing it here. I just though, if I'm going to write a whole proposal 
> with examples and motivation, it would be easier to demonstrate it and 
> discuss in with the community If I just went ahead and wrote the whole thing 
> and sent the link. This way it would be clearer to the reader and the 
> discussed changes would be accurately reflected by the commits I'd make to my 
> proposal.
> 
> Original Message
> 
>> On Jun 10, 2017, at 2:38 AM, Daryle Walker via swift-evolution 
>> > wrote:
>> 
>> On Fri, Jun 9, 2017 at 5:32 PM, Gor Gyolchanyan > > wrote:
>> Forked swift-evolution, created a draft proposal:
>> 
>> https://github.com/technogen-gg/swift-evolution/blob/master/proposals/-uniform-initialization.md
>>  
>> 
>> 
>> This is my first proposal, so I might have missed something or composed it 
>> wrong, so please feel free to comment, fork and send pull requests. 
>> 
>> 
>> This is a very interesting read. We did not discuss the 'indirect' idea at 
>> all on this list. 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Riley Testut via swift-evolution]

> Apparently the proposal is not updated yet. `EncodingError` and 
> `DecodingError` enums were said to be added as part of the move to the 
> Standard Library.
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html>
> 
> Regards,
> Anders

Ah thanks, glad to hear this!

> On Apr 25, 2017, at 6:30 PM, Anders Ha <he...@andersio.co> wrote:
> 
>> 
>> On 26 Apr 2017, at 9:11 AM, Riley Testut via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I’m sure this has already been discussed, but why are the methods throwing 
>> NSErrors and not Enums? If I’m remembering correctly, the original reason 
>> for this was because this was meant to be a part of Foundation. Now that 
>> this is in the Standard Library, however, it seems strange that we’re still 
>> using NSError.
>> 
> 
> Apparently the proposal is not updated yet. `EncodingError` and 
> `DecodingError` enums were said to be added as part of the move to the 
> Standard Library.
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html
>  
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html>
> 
> Regards,
> Anders
> 
>> Second question that again I’m sure was asked and answered already, but: why 
>> do we require implementations for each concrete numeric type (Int, Int8, 
>> Int16, Float, etc), instead of using protocols (such as the new Integer 
>> protocols)?
>> 
>>> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>>>  
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md>
>>> 
>>> Hello Swift Community,
>>> 
>>> The review of SE-0166 “Swift Archival & Serialization” ran from April 
>>> 6...12, 2017. The proposal is accepted with some minor modifications. 
>>> Specifically, the core protocols and types will be sunk down into the Swift 
>>> standard library for more tight integration with the Swift language and 
>>> compiler, and the operations specifically involving Foundation’s “Data” 
>>> type will be removed. The proposal document has been updated with more 
>>> detail. Thank you everyone for participating in this review!
>>> 
>>> - Doug
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Riley Testut via swift-evolution]

I’m sure this has already been discussed, but why are the methods throwing 
NSErrors and not Enums? If I’m remembering correctly, the original reason for 
this was because this was meant to be a part of Foundation. Now that this is in 
the Standard Library, however, it seems strange that we’re still using NSError.

Second question that again I’m sure was asked and answered already, but: why do 
we require implementations for each concrete numeric type (Int, Int8, Int16, 
Float, etc), instead of using protocols (such as the new Integer protocols)?

> On Apr 25, 2017, at 3:59 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md
>  
> 
> 
> Hello Swift Community,
> 
> The review of SE-0166 “Swift Archival & Serialization” ran from April 6...12, 
> 2017. The proposal is accepted with some minor modifications. Specifically, 
> the core protocols and types will be sunk down into the Swift standard 
> library for more tight integration with the Swift language and compiler, and 
> the operations specifically involving Foundation’s “Data” type will be 
> removed. The proposal document has been updated with more detail. Thank you 
> everyone for participating in this review!
> 
>   - Doug
>   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] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Riley Testut via swift-evolution]

My 2c on access control regarding extensions + global variables:

Another annoyance from SE-0025 was that "private" and "fileprivate" modifiers 
meant the same thing when dealing with extensions and global variables. 
Obviously this was for good reasons, but still seemed weird.

Regarding extensions now, I think it's nice that they actually can mean 
different things, so I definitely agree this is the right answer. I commonly 
mark extensions "private" simply to have the members inside default to that 
access level, rather than write "private" for each one. Now, should I have a 
collection of members that should be fileprivate, I can use a fileprivate 
extension for the same thing.

Regarding global variables, however, I actually thing the current behavior 
should remain. A truly private global variable makes no sense, and so declaring 
fileprivate vs private should continue to have the same behavior. While a very 
logical argument could be made that we should just enforce "fileprivate" for 
such instances, I personally think this runs counter to progressive disclosure. 
A programmer should only have to learn about fileprivate when trying to share 
internals of a type with another type, and not when simply declaring a global 
variable.

Playing devil's advocate, however, this might be a good thing. Now, when the 
programmer tries to declare a private global variable, they'll learn about the 
"fileprivate" modifier, and from that they'll learn what that does. So this 
would actually be a way of informing the programmer about fileprivate in the 
first place.

Again, I think keeping private/fileprivate as functionally equivalent for 
global variables is "easiest", and it's what my vote is for. Additionally, as 
weird as it might be to have two access control levels that "do the same thing" 
in this case, I think it makes more sense than being unable to use "private" at 
all. But since there are valid arguments to enforce fileprivate, I won't argue 
too much :-) I strongly believe access control on extensions should remain, 
however, and that private/fileprivate should have different results.

(Obviously, this doesn't affect public/internal modifiers)


> On Apr 22, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Sat, Apr 22, 2017 at 4:05 PM, Jose Cheyo Jimenez  
>> wrote:
>> 
>> 
>>> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu  wrote:
>>> 
 On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution 
  wrote:
 
 
> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> The "Access Control" section of the Swift 3 book says the following:
>> You can mark an extension with an explicit access-level modifier (for 
>> example, private extension) to set a new default access level for all 
>> members defined within the extension.
> The behavior of "private extension" in Swift 3 was a deviation from that 
> model, justified because "private" as a default would have meant that 
> nothing in the extension could ever be called. But it was still contrary 
> to the model suggested by the Swift documentation. 
> 
> Given the highly restrictive behavior of "private" in Swift 3 and the 
> documentation quoted above, it seems unlikely that a developer would 
> intentionally use "private extension" to mean "please make all this stuff 
> visible to the entire file"—it would have worked, but it seems an odd way 
> to write it. If that were the intention, I think "fileprivate extension" 
> would have been more likely.
> 
> I think the change to the behavior of "private extension" is in line with 
> the model proposed by SE-0169, in line with the documented behavior of 
> access control on extensions, and in line with user expectations.
> 
> -BJ
 
 I understand your point. Another aspect of SE-0169 is that fileprivate 
 should be more rare and thus meaningful when used. The current behavior 
 stays true to the goal of making fileprivate rare. 
 
 A top level private scope is effectively fileprivate so it is not totally 
 weird for the extension members to inherit the top level private scope. 
 
 When extensions gain the ability to contain properties, we should not 
 allow the access level modifiers to the extensions in the same way 
 protocol extensions prohibit its use. 
>>> 
>>> That idea would be my preference too, but it has been already written up as 
>>> a proposal, considered, and rejected.
>> 
>> Properties in extensions? AKA partials ? I was thinking disallow only when 
>> properties are introduced in the extension not in general. 
> 
> No, disallowing access modifiers on extensions.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Pitch] Improve the API Design Guidelines about protocol naming

[Riley Testut via swift-evolution]

+1 to the proposal, *especially* the addition of the RangeExpression protocol.

That being said, I agree with the critiques over the chosen name. I also can't 
remember where exactly, but I do remember at some point hearing that the 
-Protocol suffix should be added to protocol names if needed to disambiguate 
them from concrete types (and have followed this convention in my own projects).

While I actually believe taken at face value "RangeExpression" is a better name 
than "RangeProtocol", I believe RangeProtocol is better overall as it is more 
consistent with the naming conventions. (As an aside, I much preferred Swift 
2's "-Type" suffix naming convention for protocols. However, since we're no 
longer using that, might as well be consistent with other protocol names.)

> On Apr 20, 2017, at 12:21 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> Well, IteratorProtocol, LazySequenceProtocol weren't imported from ObjC.
> 
> They set a precedent for the -Protocol suffix.
> 
> Now, even if you don't like RangeProtocol, this doesn't make RangeExpression 
> better.
> 
> "Expression" and `1...` don't belong to the same level of the language: one 
> is a concept of that belongs to the compiler, when the other is a plain value 
> used in a program:
> 
> When a program does `1 + 2`, it both sums two integers, and builds a 
> expression from two other expressions and an operator. Both are true. Yet 1 
> is of type `Integer`, not `IntegerExpression`.
> 
> Currently all types of the standard library belong the program realm, not to 
> the compiler realm. I wish we wouldn't break this practice, and avoid 
> `RangeExpression`.
> 
> That's why I suggest `RangeProtocol`. Other options could be `Ranging`, 
> `Bounds`...
> 
> Gwendal Roué
> 
> 
>> Le 19 avr. 2017 à 23:35, Jordan Rose  a écrit :
>> 
>> That was probably about the ObjC importer, which does this (appends 
>> "Protocol") when there's a class and protocol with the same name in the same 
>> module. That doesn't necessarily mean it's the right thing to put in the API 
>> guidelines, though.
>> 
>> Jordan
>> 
>> 
>>> On Apr 19, 2017, at 10:59, Gmail via swift-evolution 
>>>  wrote:
>>> 
>>> I seem to recall that something (maybe a WWDC session) mentioned something 
>>> about protocols that in essence represent a single type would have the 
>>> Protocol-suffix. 
>>> 
>>> Unfortunately I couldn’t find it (yet?). The closest I’ve found so far is 
>>> http://asciiwwdc.com/2014/sessions/407 but I’m not sure that was it.
>>> > essentially when there's a conflict between a class name and a protocol 
>>> > name, we'll append protocol to the name of the protocol.
>>> 
>>> David
>>> 
> On 19 Apr 2017, at 17:55, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
> Le 19 avr. 2017 à 17:23, Gwendal Roué  a écrit :
> 
> Re: [swift-evolution] [Review] SE-0172: One-sided Ranges
> 
> "RangeExpression" is an unexpected name. I was expecting "RangeProtocol", 
> as in IteratorProtocol and LazySequenceProtocol. We need a consistent 
> suffix for protocols that can't be named in -able,  -ible, or named with 
> a simple noun because the noun is already used by a concrete type. 
> "-Protocol" should be that prefix: RangeProtocol.
 
 A detailed look at API Design Guidelines [1] shows that this subject is 
 not addressed:
 
>   • Protocols that describe what something is should read as nouns (e.g. 
> `Collection`).
>   • Protocols that describe a capability should be named using the 
> suffixes `able`, `ible`, or `ing` (e.g. `Equatable`, `ProgressReporting`).
 
 Nothing is said for "protocols that describe what something but can't be 
 named as nouns", or "protocols that describe a capability but can't be 
 named using the suffixes able, ible, or ing".
 
 For example: the name of the protocol for all ranges discussed with 
 SE-0172 should be addressed by the first rule (because the protocol 
 describes what something is rather than a capability). But that protocol 
 can't be named Range because Range is already taken.
 
 Such a situation comes rather easily:
 
 - in an evolving code base, when a protocol is added on top of an existing 
 type hierarchy which should be preserved (RangeProtocol added on top of 
 Range, ClosedRange, etc.)
 - at the birth of a code base, when a protocol coexists with a concrete 
 type which rightfully deserves the noun claimed by the protocol.
 
 IteratorProtocol and LazySequenceProtocol have set a precedent: maybe we 
 should have the API Design Guidelines evolve with a third rule:
 
 + When a protocol can't be named with a noun, or with an `able`, `ible`, 
 or `ing` suffix, the protocol should be named using the suffix `Protocol` 
 (e.g. 

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

[Riley Testut via swift-evolution]

Extremely happy to see this outcome. Thank you Core Team for dealing with the 
seemingly never-ending arguments about access control, hopefully the majority 
of that is behind us now :^)

> On Apr 17, 2017, at 5:25 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
> 
> Hello Swift Community,
> 
> The review of SE-0169 "Improve Interaction Between `private` Declarations and 
> Extensions” ran from April 6...11, 2017. The proposal is accepted.
> 
> This topic has been highly controversial for a long time, both during Swift 
> 3’s development (when SE-0025 was introduced) and during Swift 4 (including 
> SE-0159 and other proposals). There is no solution that will make everyone 
> happy: maintaining the status quo makes “fileprivate” too common and 
> therefore not meaningful when it occurs in source; removing or diluting 
> scope-level access control (as in SE-0159 and this proposal) takes away a 
> tool that is in use by Swift developers; and adding more levels of access 
> control complicates the language.
> 
> The core team feels that this proposal makes private access align more 
> closely with the goals of the language:
> 
> It supports the notion that extensions are a code-organization tool: one 
> should be able to break up a type’s definition into several extensions to 
> improve the clarity of that code, without having to open up access or 
> otherwise view the members in different extensions as completely-distinct 
> entities. The core team expects future language evolution to reinforce the 
> notion that extensions are more of a code organization tool than distinct 
> entities, e.g., allowing stored properties to be introduced in an extension.
> It makes private more usable as the default sub-internal access level, which 
> supports progressive disclosure of the access control system and better 
> matches with programmer’s expectations about what private access means.
> It makes fileprivate more meaningful, because it is only needed for those 
> cases where one is reaching across types (or among types and globals) within 
> a file. It will also become more rare, which matches well with its longer, 
> descriptive name.
> 
> The proposal’s acceptance includes one modification: extensions of a given 
> type that reside in a single file that is different from the file that 
> defines the type itself will have access to the private members of all other 
> extensions in that file. For example:
> 
> // FileA.swift
> struct A {
>   private var aMember : Int 
> }
> 
> // FileB.swift
> extension A {
> private func foo() {
> bar()// ok, foo() does have access to bar()
> }
> }
> 
> extension A {
> private func bar() {
> aMember = 42  // not ok, private members may not be accessed outside 
> their file.
> }
> }
> 
> The proposal has already been updated to reflect this change, which better 
> reflects the notion that extensions are a code-organization tool.
> 
> The core team considers the access-control matter closed for Swift 4 and will 
> not be reviewing any further proposals in this area.
> 
>   - Doug
>   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-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> I think its important to point out that its more than aesthetics: because the 
> simple file and extensions scenario are so common, it forces us to use both 
> private and fileprivate fairly regularly, which increases the total number of 
> access control to work with on a daily basis. And I think that’s the 
> important point. That’s why open is a success IMHO: because it only needs to 
> be used rarely, it provided the required functionality without increasing the 
> number of access modifiers that needed to be used regularly.

I agree 100%. I’ve never been a fan of open, and still disagree with the 
rationale for why it was added. However, because it does follow Swift’s 
progressive disclosure emphasis, and because it does accomplish what it was 
designed to do, I’ve made peace with it.

Fileprivate is different. It was intended to be used rarely, as another form of 
progressive disclosure, and when it was used, it had meaning. However, as has 
been discussed many times, this is not the case. Fileprivate, for a multitude 
of reasons, is used far more frequently than anticipated (fileprivate is 
certainly used way more than private in my own projects), and as a result loses 
its meaning. When looking at a fileprivate declaration, there is no way to know 
whether it is intended to be exposed to separate types, or simply to extensions 
of the same type.

Again, I personally think access control was far simpler in Swift 2. However, 
because the idea of scoped access clearly has value to many developers, I am 
okay with adding that functionality to the language. By allowing extensions to 
access private variables, fileprivate has actual meaning again (which was the 
original intention) and is also something that many developers may never need 
to use.

FWIW, I really don’t view this proposal as just a stop-gap, I think accepting 
this proposal will genuinely be the best option for Swift in general. I 
personally don’t like the idea of renaming private to scoped, since I think 
private and fileprivate are better terms in general. I just want private member 
access in my extensions for God’s sake :^)

> On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution 
>  wrote:
> 
> I think its important to point out that its more than aesthetics: because the 
> simple file and extensions scenario are so common, it forces us to use both 
> private and fileprivate fairly regularly, which increases the total number of 
> access control to work with on a daily basis. And I think that’s the 
> important point. That’s why open is a success IMHO: because it only needs to 
> be used rarely, it provided the required functionality without increasing the 
> number of access modifiers that needed to be used regularly.

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Riley Testut via swift-evolution]

> Dynamic programming comes to mind.


Wouldn’t you then be able to use Array(repeating:count:) and repeat 0 (or 
something else) to achieve this then?

Yes, less performant than alloc’ing array (since we need to fill in default 
values), but doing otherwise would go against Swift’s safety model. If you 
truly wanted that behavior, you can use the UnsafePointer methods anyway 
(AFAIK).

> On Apr 16, 2017, at 9:18 PM, Saagar Jha <saa...@saagarjha.com> wrote:
> 
> Dynamic programming comes to mind.
> 
> Saagar Jha
> 
>> On Apr 16, 2017, at 19:33, Riley Testut <rileytes...@gmail.com 
>> <mailto:rileytes...@gmail.com>> wrote:
>> 
>> My bad, should have phrased my response better :^)
>> 
>> Under what circumstances would you need to be able to assign elements in an 
>> array out of order, while also requiring Array size/performance? (Genuinely 
>> curious, not trying to attack).
>> 
>> IMO, if the differences between Array and Dictionary would cause that much 
>> of an issue for your implementation, my guess is you have more important 
>> priorities than the need to assign elements out-of-order  I don't think 
>> we'd need to add another type to the standard library for this use case.
>> 
>> On Apr 16, 2017, at 11:22 AM, Saagar Jha <saa...@saagarjha.com 
>> <mailto:saa...@saagarjha.com>> wrote:
>> 
>>> A Dictionary uses a lot more space than an Array, though, and allow for 
>>> bogus keys like “-1”, etc.
>>> 
>>> Saagar Jha
>>> 
>>>> On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>> Personally, the only valid use-case I can think of is when you want to 
>>>>> initialise an Array’s elements out-of-order - i.e., you want to set a 
>>>>> value for myArray[2] despite myArray[0] and [1] not being populated. In 
>>>>> that case, it would be better to have some kind of SparseArray type, and 
>>>>> for us to have a proper API for unsafe initialisation of stdlib types. 
>>>> 
>>>> Wouldn't the same functionality be accomplished by a Dictionary with Int 
>>>> as the key type?
>>>> 
>>>> On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>>>> I'd actually say the #1 reason not to add this feature is that a lot of 
>>>>>> developers don't seem to understand this, and they're likely to use the 
>>>>>> feature to make their code try to continue in the face of programmer 
>>>>>> error instead of trapping like it properly should. A program in an 
>>>>>> inconsistent state is dangerous; best to stop it quickly before it does 
>>>>>> some damage.)
>>>>> 
>>>>> Right, so I think the reason is actually that a lot of developers don’t 
>>>>> understand what an Array is. There are two use-cases for an Array:
>>>>> 
>>>>> 1) As a string of items, don’t care about the length. The maximum prior 
>>>>> knowledge you can have is that the order may or may not be significant. 
>>>>> This includes operations like iteration, mapping, reducing and filtering.
>>>>> 2) As a string of items of specific length. You have prior knowledge 
>>>>> about what you expect to find at each location. This includes operations 
>>>>> like random-access subscripting, which is what we’re talking about.
>>>>> 
>>>>> Basically, the interesting part of a statement such as “let someValue = 
>>>>> myArray[2]” is: why index 2? What’s so special about that element; why 
>>>>> couldn't someValue be the item at any index N instead? It’s because we 
>>>>> know to expect something of special significance at index 2.
>>>>> 
>>>>> In that case, the only time myArray[2] will fail is when your prior 
>>>>> knowledge breaks down. The type-system has no way to encode and check for 
>>>>> the length of an Array, and that has allowed somebody to pass in a bad 
>>>>> value. So what to do?
>>>>> 
>>>>> A) If you absolutely require a value for myArray[2]: Insert a 
>>>>> precondition check.
>>>>> B) If you can still continue without myArray[2]: Check the length of the 
>>>>> Array. Your logic will be branching

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> You’re right, I overgeneralized. Let me correct myself:
> 
> From what I’ve seen so far [*], using extensions for "code organization" 
> often results in spaghetti code.
> 
> [*] Observed as a contractor; iOS platform; average Joe's code.


Fair :-)

Another use case for extensions I had forgotten about that I have used 
extensively, however, is using to group private or public members together, and 
have the access control level of the extension apply to each member in the 
extension (by default). Typically, I’ll declare the properties and initializers 
in the main type declaration, and then all public methods I’ll place in a 
“public” extension, and all private methods I’ll place in a “private” 
extension. This IMO is a great win for code readability, and another thing that 
I have lost the ability to do without using file private.

> On Apr 17, 2017, at 1:04 AM, Rudolf Adamkovič  wrote:
> 
> On 17 Apr 2017, at 01:46, Riley Testut  wrote:
>> 
>> So while you personally may not use extensions, calling the use of them 
>> "spaghetti code" is rather misguided IMO.
> 
> You’re right, I overgeneralized. Let me correct myself:
> 
> From what I’ve seen so far [*], using extensions for "code organization" 
> often results in spaghetti code.
> 
> [*] Observed as a contractor; iOS platform; average Joe's code.
> 
> Thanks!
> 
> R+
> 

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

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Riley Testut via swift-evolution]

My bad, should have phrased my response better :^)

Under what circumstances would you need to be able to assign elements in an 
array out of order, while also requiring Array size/performance? (Genuinely 
curious, not trying to attack).

IMO, if the differences between Array and Dictionary would cause that much of 
an issue for your implementation, my guess is you have more important 
priorities than the need to assign elements out-of-order  I don't think we'd 
need to add another type to the standard library for this use case.

> On Apr 16, 2017, at 11:22 AM, Saagar Jha <saa...@saagarjha.com> wrote:
> 
> A Dictionary uses a lot more space than an Array, though, and allow for bogus 
> keys like “-1”, etc.
> 
> Saagar Jha
> 
>>> On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Personally, the only valid use-case I can think of is when you want to 
>>> initialise an Array’s elements out-of-order - i.e., you want to set a value 
>>> for myArray[2] despite myArray[0] and [1] not being populated. In that 
>>> case, it would be better to have some kind of SparseArray type, and for us 
>>> to have a proper API for unsafe initialisation of stdlib types. 
>> 
>> Wouldn't the same functionality be accomplished by a Dictionary with Int as 
>> the key type?
>> 
>> On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>>> I'd actually say the #1 reason not to add this feature is that a lot of 
>>>> developers don't seem to understand this, and they're likely to use the 
>>>> feature to make their code try to continue in the face of programmer error 
>>>> instead of trapping like it properly should. A program in an inconsistent 
>>>> state is dangerous; best to stop it quickly before it does some damage.)
>>> 
>>> Right, so I think the reason is actually that a lot of developers don’t 
>>> understand what an Array is. There are two use-cases for an Array:
>>> 
>>> 1) As a string of items, don’t care about the length. The maximum prior 
>>> knowledge you can have is that the order may or may not be significant. 
>>> This includes operations like iteration, mapping, reducing and filtering.
>>> 2) As a string of items of specific length. You have prior knowledge about 
>>> what you expect to find at each location. This includes operations like 
>>> random-access subscripting, which is what we’re talking about.
>>> 
>>> Basically, the interesting part of a statement such as “let someValue = 
>>> myArray[2]” is: why index 2? What’s so special about that element; why 
>>> couldn't someValue be the item at any index N instead? It’s because we know 
>>> to expect something of special significance at index 2.
>>> 
>>> In that case, the only time myArray[2] will fail is when your prior 
>>> knowledge breaks down. The type-system has no way to encode and check for 
>>> the length of an Array, and that has allowed somebody to pass in a bad 
>>> value. So what to do?
>>> 
>>> A) If you absolutely require a value for myArray[2]: Insert a precondition 
>>> check.
>>> B) If you can still continue without myArray[2]: Check the length of the 
>>> Array. Your logic will be branching anyway in this case, to account for the 
>>> value (and subsequent values) being/not being present.
>>> 
>>> 
>>> Personally, the only valid use-case I can think of is when you want to 
>>> initialise an Array’s elements out-of-order - i.e., you want to set a value 
>>> for myArray[2] despite myArray[0] and [1] not being populated. In that 
>>> case, it would be better to have some kind of SparseArray type, and for us 
>>> to have a proper API for unsafe initialisation of stdlib types. 
>>> 
>>> - Karl
>>> ___
>>> 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-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> Using extensions for "code organization" is another word for writing 
> spaghetti code.

Using extensions for code organization is a practice established and 
recommended by the Core Team from the very beginning (such as this blog post 
from August 2014: https://developer.apple.com/swift/blog/?id=8). 

Additionally, here's Chris Lattner himself in regards to extensions:

> This design is true to the existing design of Swift: we want to encourage the 
> implementation of types to be freely broken into extensions.  This alignment 
> with extension oriented programming was the one important virtue of the Swift 
> 1/2 access control design that Swift 3 lost.


So while you personally may not use extensions, calling the use of them 
"spaghetti code" is rather misguided IMO.

Regardless, as a final plea to the Core Team regarding this proposal: 
unsurprisingly, the people who are on this mailing list represent a specific 
subset of Swift users, and not the Swift user base as a whole. The arguments 
against this proposal I truly believe are not relevant to the "average" Swift 
user. 

A newcomer to Swift would probably begin by putting all logic for a class in 
one class declaration, and using "private" for private members (as is 
expected). However, once they find out about the Swift practice of using 
extensions to separate out logic, they will hit a roadblock as they will be 
unable to use private members as is, and rather than understand why, they very 
well may simply choose to never adopt an extension-based workflow, which is 
unfortunate. However, if this proposal was accepted, they could easily go from 
one class declaration to one with extensions, without even having to learn 
about fileprivate.

I truly believe this lessening of restrictions over private member in 
extensions (which is used by practically all levels of Swift programmers) is 
more important to the language than the ability to truly restrict types to just 
the original class scope (which I believe is primarily used by more "advanced" 
users). Experienced users know what they're doing, and can deal with 
shortcomings (such as prefixing truly private members with underscores). 
Newcomers/"average" users don't as much, and this friction is a much bigger 
deal for them. Also, while some have mentioned that this adds complexity to the 
access control system because types are now a factor, to that I say: this is 
purely a theoretical issue. In practice, developers don't care that this is 
case, and just care that the access control logic makes sense when using it. As 
someone who's had to explain why fileprivate is necessary many times to new 
Swift developers when using extensions, I can assure you that using this 
proposed private definition makes more intuitive sense to them.

To sum up, please don't lessen the experience of the average Swift programmer 
simply because there are some gains for the more "advanced" developers; 
obviously not everyone can be happy, but I believe in this case this proposal 
will satisfy the vast vast majority of Swift programmers (aka, people not on 
this mailing list).

Riley Testut

> On Apr 16, 2017, at 1:02 PM, Rudolf Adamkovic via swift-evolution 
>  wrote:
> 
> -1 from me.
> 
> Using extensions for "code organization" is another word for writing 
> spaghetti code.
> 
> It results in types with many responsibilities. In such cases, it's time to 
> extract collaborator types.
> 
> But it sure looks prettier.
> 
> R+
> 
> Sent from my iPhone
> 
>>> On 7 Apr 2017, at 10:56, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> Strong -1.  Just rename ‘fileprivate’ to be less annoying.
>> 
>> This proposal will make things even worse than they are currently.  We will 
>> regret it just as much, if not more than, 0025.  As others have mentioned, 
>> it is actively harmful:
>> • It once again changes the meaning of private
>> • It takes away most of the actual power of private (vs fileprivate). (I was 
>> for returning to the simpler Swift 2 access, but when I did use private, I 
>> used it to limit access to just a few lines of code. This proposal gets rid 
>> of the last ounce of usefulness of ‘private’ for me, and only has the virtue 
>> of a less annoying name).
>> • It is the camel’s nose in the tent for type-based access (people will ask 
>> for future versions to be available in the type in the submodule, module, 
>> and then public… but we will be unable to give it to them)
>> • It breaks the same code that 0159 would have broken
>> • It will be a nightmare to teach/learn
>> 
>> Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. 
>> Fileprivate is the best access levels for a lot of cases, it just has an 
>> annoying name.  Given our constraints, I now believe the only sane choice 
>> left to us is to make fileprivate easier to use (as opposed to making 
>> private more like 

Re: [swift-evolution] [Pitch] Adding safety to arrays

[Riley Testut via swift-evolution]

> Personally, the only valid use-case I can think of is when you want to 
> initialise an Array’s elements out-of-order - i.e., you want to set a value 
> for myArray[2] despite myArray[0] and [1] not being populated. In that case, 
> it would be better to have some kind of SparseArray type, and for us to have 
> a proper API for unsafe initialisation of stdlib types. 

Wouldn't the same functionality be accomplished by a Dictionary with Int as the 
key type?

On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution 
 wrote:

>> I'd actually say the #1 reason not to add this feature is that a lot of 
>> developers don't seem to understand this, and they're likely to use the 
>> feature to make their code try to continue in the face of programmer error 
>> instead of trapping like it properly should. A program in an inconsistent 
>> state is dangerous; best to stop it quickly before it does some damage.)
> 
> Right, so I think the reason is actually that a lot of developers don’t 
> understand what an Array is. There are two use-cases for an Array:
> 
> 1) As a string of items, don’t care about the length. The maximum prior 
> knowledge you can have is that the order may or may not be significant. This 
> includes operations like iteration, mapping, reducing and filtering.
> 2) As a string of items of specific length. You have prior knowledge about 
> what you expect to find at each location. This includes operations like 
> random-access subscripting, which is what we’re talking about.
> 
> Basically, the interesting part of a statement such as “let someValue = 
> myArray[2]” is: why index 2? What’s so special about that element; why 
> couldn't someValue be the item at any index N instead? It’s because we know 
> to expect something of special significance at index 2.
> 
> In that case, the only time myArray[2] will fail is when your prior knowledge 
> breaks down. The type-system has no way to encode and check for the length of 
> an Array, and that has allowed somebody to pass in a bad value. So what to do?
> 
> A) If you absolutely require a value for myArray[2]: Insert a precondition 
> check.
> B) If you can still continue without myArray[2]: Check the length of the 
> Array. Your logic will be branching anyway in this case, to account for the 
> value (and subsequent values) being/not being present.
> 
> 
> Personally, the only valid use-case I can think of is when you want to 
> initialise an Array’s elements out-of-order - i.e., you want to set a value 
> for myArray[2] despite myArray[0] and [1] not being populated. In that case, 
> it would be better to have some kind of SparseArray type, and for us to have 
> a proper API for unsafe initialisation of stdlib types. 
> 
> - Karl
> ___
> 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-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> The Core Team has rejected making such a major change in the interpretation 
> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
> question is whether extensions of the same type within a file should be 
> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
> the deadline for making that change; if it, too, is rejected, 'private' will 
> be purely lexical forever.

If private really is tied to scopes now and forever, I certainly have no doubt 
these change should be accepted to alleviate the biggest annoyance with it.

Should this be accepted, to me, using "fileprivate" serves as a flag that 
another type has privileged access to another type's private members. 
Unfortunately, because fileprivate is needed for extensions of the same type, 
then the keyword loses this meaning. If I choose to use extensions to define a 
type (as was a practice greatly encouraged in Swift 1/2), fileprivate serves no 
self-documentation role beyond "private".

Additionally, I truly believe this proposal would align the access control with 
what newcomers to the language are already familiar with. When they adopt the 
Swift practice of multiple extensions, they'll be confused why they have to 
change private to fileprivate, and may instead just decide to stick it all in 
one definition. Anecdotally, that's certainly what I expected when Swift 3 was 
released, and I've now stopped using extensions for types as much simply 
because of fileprivate.

> On Apr 7, 2017, at 10:01 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> If private is required to be tied to types forever and always, then yes, this 
> proposal should be accepted. To do otherwise is to suggest that the use of 
> "private" by beginners and the use of same-file extensions by beginners are 
> incompatible. The former is silly; "private" is what beginners will naturally 
> reach for. The latter is possible, but historically the use of same-file 
> extensions has been quite idiomatic. So, I reluctantly agree we should accept 
> this proposal.
> 
> -BJ
> 
>> On Apr 7, 2017, at 10:34 PM, John McCall via swift-evolution 
>>  wrote:
>> 
>> 
 On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution 
  wrote:
 
 What is your evaluation of the proposal?
>>> 
>>> If this is the last option we have to change the status quo, any renaming 
>>> is off the table, no further changes after Swift 4, and it's either this or 
>>> being stuck with 'fileprivate' until the end of time, then +1 from me. It 
>>> will increase the convenience of access control for people like me who see 
>>> types and their extensions as parts of the same entity, just spread 
>>> visually across neighboring blocks. In almost any other language these two 
>>> would indeed be one entity, since most languages don't have any way of 
>>> dividing types into pieces this way.
>>> 
>>> However, IMHO any of these would be a better solution:
>> 
>> I'd like to respond briefly to this to clarify the Core Team's decisions 
>> about what solutions are under consideration, both now and in the future.  
>> By doing this, I don't mean to pressure you towards any particular stance.  
>> The Core Team asked for this to be proposed because we wanted to know how 
>> the community felt about it; we are not specifically trying to get it 
>> approved, at least as a group.
>> 
>>> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' 
>>> back to 'private'
>> 
>> The Core Team has rejected making such a major change in the interpretation 
>> of 'private'.  'private' will be tied to scopes, now and forever.  The only 
>> question is whether extensions of the same type within a file should be 
>> considered part of the same scope for the purposes of 'private'.  Swift 4 is 
>> the deadline for making that change; if it, too, is rejected, 'private' will 
>> be purely lexical forever.
>> 
>>> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' 
>>> suggestion that Vladimir made today)
>> 
>> The Core Team is willing to consider adding a new keyword to replace 
>> 'fileprivate', but not in Swift 4.
>> 
>> Speaking just for myself, I don't think we'd accept such a change purely for 
>> aesthetics; it would have to be because 'fileprivate' seemed inappropriate 
>> for some new generalization, e.g. if we added sub-file submodules and wanted 
>> 'fileprivate' to allow access only within the submodule.  That is assuming a 
>> lot about how a future submodule feature would work, and we aren't going to 
>> design that feature specifically with a goal of replacing this keyword, and 
>> frankly we don't know when we're going to take that on at all.  I would 
>> caution people against assuming that 'fileprivate' will be renamed.
>> 
>>> 3) Postpone this until we add submodules, but with the assumption that it 
>>> will be possible to make some 

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

> Presumably, proponents of SE-0025. That is, after all, an explicit part of 
> that design, reviewed and approved by the Swift community and core team.

I'd be curious how many people actually are doing this though. My understanding 
is this practice is not that common overall.

Ultimately though, yes with any change like this there will be compromises. I 
personally believe the loss of this situation you're describing is far less 
than what there is to gain from this proposal.

> On Apr 6, 2017, at 5:48 PM, Xiaodi Wu  wrote:
> 
> On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka  
> wrote:
>>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> `private` works for extensions exactly how the authors of SE-0025 intended 
>>> it to do. Your comments do not address what would happen for those people 
>>> who are making use of this functionality currently to isolate methods to 
>>> the extension only.
>> 
>> Who is currently doing that?
> 
> Presumably, proponents of SE-0025. That is, after all, an explicit part of 
> that design, reviewed and approved by the Swift community and core team.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.

My previous email was in response to this sorry. Ugh, mailing lists.

> On Apr 6, 2017, at 5:43 PM, Riley Testut <rileytes...@gmail.com> wrote:
> 
> While valid, my understanding is that the use of extensions that should have 
> access to private members is more common than the use of extensions to 
> explicitly prevent access.
> 
> More importantly though, using extensions to prevent access to private 
> members can be accomplished by declaring the extensions in another file. The 
> reverse is not true; extensions that should have access to private members is 
> impossible. 
> 
> tl;dr; using extensions as a means to disallow access to private members is 
> (from what I understand) far less common, and if someone really wanted to do 
> that, they could instead declare the extensions in another file.
> 
>> On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>> 
>>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> I cannot express how strongly I believe this is the direction Swift should 
>>> go, so a huge, gigantic,
>>> 
>>> +1
>>> from me.
>>> 
>>> After thinking it over, I do not have any qualms with fileprivate itself. I 
>>> think that the functionality provided by fileprivate is valuable, and I 
>>> also agree it shouldn’t be the default.
>>> 
>>> However
>>> 
>>> This proposal would solve the problems introduced by Swift 3’s private, 
>>> which has resulted in me defaulting to fileprivate for almost all “private” 
>>> variables due to my heavy use of extensions.
>>> 
>>> Beyond me, however, I can attest that when teaching others Swift, they 
>>> initially are confused why private doesn’t work for extensions. To them, it 
>>> does not feel intuitive, and it certainly doesn’t to me either.
>> 
>> `private` works for extensions exactly how the authors of SE-0025 intended 
>> it to do. Your comments do not address what would happen for those people 
>> who are making use of this functionality currently to isolate methods to the 
>> extension only.
>>  
>>> One argument I saw throughout these discussions was that this encourages 
>>> people to put all their code in one file. To that I ask, how is this any 
>>> different than what we have now? Fileprivate doesn’t fix this either.
>>> 
>>> Ultimately, this keeps things almost exactly the same as what we have now, 
>>> but addresses the concerns of many in the Swift community. If you don’t 
>>> want to use private with extensions, people can simply not use private 
>>> variables in extensions.
>>> 
>>> I genuinely believe this will satisfy the majority who were upset by 
>>> fileprivate, and I do not think it will affect those who were in favor of 
>>> fileprivate. So yes, again +1, and let’s please be done with this 
>>> fileprivate/private debate after this.
>>> 
>>> (Also, I personally don’t view this as a “temporary workaround” like some 
>>> others. I would be very happy if this was the private/fileprivate solution 
>>> forever).
>>> 
>>>> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> If you don't want to resolve the mistake of SE-0025 by proposing a really 
>>>> solution but not a workaround, then just leave the things where they are 
>>>> currently. Proposed "improvement" IMO is more confusing than helping.
>>>> 
>>>> Sorry, I don't buy <<..most of those proposals are not in scope for 
>>>> discussion in Swift 4 (or any later release), given the significant impact 
>>>> on source compatibility>>, because SE-0169 is also a source breaking 
>>>> change, and the problem of access modifiers is important enough to relax 
>>>> the rule of source compatibility for it, *especially if this is the last 
>>>> chance*.
>>>> Also, it seems like core team was ready to accept SE-0159(Fix Private 
>>>> Access Levels) which also has impact on source compatibility(given it 
>>>> suggested to remove scoped-private).
>>>> IMO SE-0159 + new 'scoped' keyword for scoped

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

While valid, my understanding is that the use of extensions that should have 
access to private members is more common than the use of extensions to 
explicitly prevent access.

More importantly though, using extensions to prevent access to private members 
can be accomplished by declaring the extensions in another file. The reverse is 
not true; extensions that should have access to private members is impossible. 

tl;dr; using extensions as a means to disallow access to private members is 
(from what I understand) far less common, and if someone really wanted to do 
that, they could instead declare the extensions in another file.

> On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
>> On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> I cannot express how strongly I believe this is the direction Swift should 
>> go, so a huge, gigantic,
>> 
>> +1
>> from me.
>> 
>> After thinking it over, I do not have any qualms with fileprivate itself. I 
>> think that the functionality provided by fileprivate is valuable, and I also 
>> agree it shouldn’t be the default.
>> 
>> However
>> 
>> This proposal would solve the problems introduced by Swift 3’s private, 
>> which has resulted in me defaulting to fileprivate for almost all “private” 
>> variables due to my heavy use of extensions.
>> 
>> Beyond me, however, I can attest that when teaching others Swift, they 
>> initially are confused why private doesn’t work for extensions. To them, it 
>> does not feel intuitive, and it certainly doesn’t to me either.
> 
> `private` works for extensions exactly how the authors of SE-0025 intended it 
> to do. Your comments do not address what would happen for those people who 
> are making use of this functionality currently to isolate methods to the 
> extension only.
>  
>> One argument I saw throughout these discussions was that this encourages 
>> people to put all their code in one file. To that I ask, how is this any 
>> different than what we have now? Fileprivate doesn’t fix this either.
>> 
>> Ultimately, this keeps things almost exactly the same as what we have now, 
>> but addresses the concerns of many in the Swift community. If you don’t want 
>> to use private with extensions, people can simply not use private variables 
>> in extensions.
>> 
>> I genuinely believe this will satisfy the majority who were upset by 
>> fileprivate, and I do not think it will affect those who were in favor of 
>> fileprivate. So yes, again +1, and let’s please be done with this 
>> fileprivate/private debate after this.
>> 
>> (Also, I personally don’t view this as a “temporary workaround” like some 
>> others. I would be very happy if this was the private/fileprivate solution 
>> forever).
>> 
>>> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> If you don't want to resolve the mistake of SE-0025 by proposing a really 
>>> solution but not a workaround, then just leave the things where they are 
>>> currently. Proposed "improvement" IMO is more confusing than helping.
>>> 
>>> Sorry, I don't buy <<..most of those proposals are not in scope for 
>>> discussion in Swift 4 (or any later release), given the significant impact 
>>> on source compatibility>>, because SE-0169 is also a source breaking 
>>> change, and the problem of access modifiers is important enough to relax 
>>> the rule of source compatibility for it, *especially if this is the last 
>>> chance*.
>>> Also, it seems like core team was ready to accept SE-0159(Fix Private 
>>> Access Levels) which also has impact on source compatibility(given it 
>>> suggested to remove scoped-private).
>>> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we 
>>> need.
>>> 
>>> So, -1 from me.
>>> 
>>>> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>>>> Hello Swift community,
>>>> 
>>>> The review of SE-0169 "Improve Interaction Between private Declarations and
>>>> Extensions" begins now and runs through April 11, 2017. The proposal is
>>>> available here:
>>>> 
>>>>
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>>> 
>>>> Reviews are an important part of the Swift evolution process. All re

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Riley Testut via swift-evolution]

I cannot express how strongly I believe this is the direction Swift should go, 
so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself. I 
think that the functionality provided by fileprivate is valuable, and I also 
agree it shouldn’t be the default.

However

This proposal would solve the problems introduced by Swift 3’s private, which 
has resulted in me defaulting to fileprivate for almost all “private” variables 
due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they 
initially are confused why private doesn’t work for extensions. To them, it 
does not feel intuitive, and it certainly doesn’t to me either.

One argument I saw throughout these discussions was that this encourages people 
to put all their code in one file. To that I ask, how is this any different 
than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things almost exactly the same as what we have now, but 
addresses the concerns of many in the Swift community. If you don’t want to use 
private with extensions, people can simply not use private variables in 
extensions.

I genuinely believe this will satisfy the majority who were upset by 
fileprivate, and I do not think it will affect those who were in favor of 
fileprivate. So yes, again +1, and let’s please be done with this 
fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some 
others. I would be very happy if this was the private/fileprivate solution 
forever).

> On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> If you don't want to resolve the mistake of SE-0025 by proposing a really 
> solution but not a workaround, then just leave the things where they are 
> currently. Proposed "improvement" IMO is more confusing than helping.
> 
> Sorry, I don't buy <<..most of those proposals are not in scope for 
> discussion in Swift 4 (or any later release), given the significant impact on 
> source compatibility>>, because SE-0169 is also a source breaking change, and 
> the problem of access modifiers is important enough to relax the rule of 
> source compatibility for it, *especially if this is the last chance*.
> Also, it seems like core team was ready to accept SE-0159(Fix Private Access 
> Levels) which also has impact on source compatibility(given it suggested to 
> remove scoped-private).
> IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.
> 
> So, -1 from me.
> 
> On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and
>> Extensions" begins now and runs through April 11, 2017. The proposal is
>> available here:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.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. When replying, please try to keep the proposal link at the top of
>> the message:
>> 
>>Proposal link:
>> 
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>> 
>>Reply text
>> 
>>Other replies
>> 
>> 
>>  
>> >  
>> >What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine 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,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

> On Mar 20, 2017, at 8:07 PM, Greg Parker  wrote:
> 
> This needs more explanation. It is allowed for a subclass to implement a 
> convenience initializer that has the same signature as a superclass 
> convenience initializer or a superclass designated initializer. The 
> convenience-over-convenience case is not technically overriding, but it is 
> misleading to say only that a convenience initializer cannot be overridden. 
> Do factory initializers follow exactly the same rules here as convenience 
> initializers?

Yes, that is what I meant. For simplicity, I think the factory initializer 
inheritance rules should match exactly that of convenience initializers.

> In addition: designated initializers and convenience initializers have rules 
> about which other initializers can be called from an implementation. These 
> rules are intended to guarantee that the chain of designated initializers is 
> called correctly. What are the precise rules for factory initializers calling 
> other initializers? What are the precise rules for non-factory initializers 
> calling factory initializers?

Factory initializers can call any other initializers. Since calling convenience 
initializers would still call required initializers, the chain would be correct 
(unless I’m missing something). As for other initializers calling factory 
initializers, my gut says this should not be allowed. Factory initializers are 
supposed to initialize and return a value, whereas other initializers 
implicitly assign to self. Therefore calling a factory initializer from a 
self-assigning initializer wouldn’t do much, and I don’t see any benefit to 
allowing this.


> On Mar 21, 2017, at 8:49 AM, David Rönnqvist  
> wrote:
> 
> Forgive me if that has already been discussed in the email threads prior to 
> the proposal, but what I’m missing from this proposal is a discussion of the 
> problems factory initializers solve (other than the examples at the end) and 
> an explanation of why factory initializers are the right solution to 
> that/those problems in Swift.

I can answer this anecdotally; when learning iOS development and Objective-C, 
it was (in my opinion) hard to know whether an Objective-C class was meant to 
be initialized via [[Class alloc] initWithParameters:] or [Class 
classWithParameters:]. Pre-ARC this did actually have meaning, but post ARC/iOS 
5 it just seemed to be whatever the framework developer preferred (not to 
mention that [Class new] was also another option…).

When Swift combined all these forms into one common Class(parameters:) format, 
this greatly reduced this cognitive load. However, as outlined in the proposal, 
this meant that the factory pattern had to be moved out of the initializers and 
back into class methods. Because of this, now if you want to implement the 
factory pattern, you’re bringing back this same confusion from Objective-C; the 
client has to remember whether your class is initialized via standard 
Class(parameters:) syntax, or by calling a class method 
Class.classWithParameters(). Ultimately, I don’t believe there should be a 
difference between the two for the average programmer. You want an instance of 
the class, so you should retrieve one by calling an initializer. They don’t 
need to know or care whether the initializer is directly assigning to self or 
returning a value, as long as they get the value they need.

Beyond this, however, I think the factory initializers on protocols is one of 
this proposal’s biggest wins. For protocol oriented programming, it’s nice to 
be apply to supply a default implementation so client’s don’t need to declare 
their own type. However, if you come across a new codebase/framework, you might 
not know the difference between the specific type you’re using and the protocol 
itself (or even which one is which). I’ve personally encountered this many 
times with Apple’s frameworks, such as UIActivityItemProvider and 
UIActivityItemSource (which one is the protocol and which one is the type? Hard 
to know and remember when first using them). With factory initializers on 
protocol extensions, the initializer can return a private type conforming to 
the protocol, so again there’s no need to worry about what is the concrete type 
and what is the protocol.

P.S. Phase 2 End Question

I didn’t realize until today that apparently Swift 4 Phase 2 ends tomorrow. Is 
this true, and does that mean this is now too late to make it into Swift 4?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

> What's the motivation behind using `return` rather than self-assignment, like 
> we currently have in inits for structs/enums and protocol extensions?

>From the original discussion, it seemed the general consensus was that 
>returning a value felt more natural than assigning to self. Here are some 
>snippets from the original discussion:

Myself:
> I’m not opposed to assigning to self directly in convenience initializers 
> (especially if there is already support for it in the ABI). My only concern 
> would be that it feels less “natural” to do so than to simply return a value 
> from the initializer. That being said, I think that’s a very negligible 
> disadvantage (if even that), and if assigning to self is the easiest way to 
> pull this off, I’m all for it.


Dave Abrahams:
> My instinct agrees with that.  Also, reassigning self raises the question of 
> whether an object is allocated (and partly initialized?) before the 
> reassignment.  Even if we can answer those questions in some clear way, I’d 
> rather not have them come up at all.


Stephen Christopher:
> I agree. Were I to naively try this in Swift, I would expect to use a 
> convenience initializer and return the instance I’d created. 

Ultimately I'm happy with either returning a value or assigning to self, 
depending on what the consensus is after a review.

> Is the "factory" keyword truly necessary, or could it be implied by 
> "required" and using self-assignment in the init body?

Factory initializers would be closer to convenience initializers rather than 
required ones, and I think the keyword is semantically useful. 
Convenience/required initializers are expected to return a type matching that 
of the static type, while the "factory" keyword signifies that the return value 
may not match, just be upperbounded by the static type.

Additionally, when dealing with factory initializers in protocol extensions, I 
think it is much more clear in intent that the function will return a type that 
conforms to the protocol rather than a hypothetical "instance" of the protocol 
itself.

> On Mar 17, 2017, at 1:15 PM, Zach Waldowski via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Big +1.
> 
> Two small nits/questions:
> 
> - What's the motivation behind using `return` rather than self-assignment, 
> like we currently have in inits for structs/enums and protocol extensions? I 
> didn't follow the original discussion in depth, so excuse me if this has been 
> hashed out before.
> - Is the "factory" keyword truly necessary, or could it be implied by 
> "required" and using self-assignment in the init body?
> 
> Best,
>   Zachary Waldowski
>   z...@waldowski.me
> 
> 
>> On Fri, Mar 17, 2017, at 12:26 PM, Riley Testut via swift-evolution wrote:
>> 
>> 
>> Hi again everyone!
>> 
>> Now that Swift 4 Stage 2 proposals are being considered, I thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian <ark...@icloud.com> wrote:
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
>>>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> Is there any chance of reviving this? It seems to me that since this would 
>>>> require Swift initializers to be implemented internally in such a way that 
>>>> they can return a value (as Objective-C init methods do), it may affect 
>>>> ABI stability and thus may be germane to the current stage of Swift 4 
>>>> development.
>>>&g

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

Hi again everyone!

Now that Swift 4 Stage 2 proposals are being considered, I thought it might be 
time to revisit this proposal and see if it might align with the goals set 
forth for Swift 4.

As a quick tl;dr, this proposal describes a new "factory initializer" that 
would allow you to return a value from an initializer. This would have several 
benefits, as mentioned in the proposal itself as well as throughout this 
mailing list. For convenience, here's a link to the proposal on GitHub: 
https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md

Would love to hear any more comments on this proposal, and if we feel this is 
appropriate for considering for Swift 4 I'll happily re-open the pull request!

Riley Testut

> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian <ark...@icloud.com> wrote:
> 
> i would appreciate this feature.
> 
> For unexperienced developers, its often hard to recognize *when* factory is a 
> good fit to do the job, and how exactly approach the implementation. I 
> imagine having this feature built into the language may help to choose and 
> implement factory when its the right thing to do.
> 
>> On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Is there any chance of reviving this? It seems to me that since this would 
>> require Swift initializers to be implemented internally in such a way that 
>> they can return a value (as Objective-C init methods do), it may affect ABI 
>> stability and thus may be germane to the current stage of Swift 4 
>> development.
>> 
>> Charles
>> 
>>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Recently, I proposed the idea of adding the ability to implement the "class 
>>> cluster" pattern from Cocoa (Touch) in Swift. However, as we discussed it 
>>> and came up with different approaches, it evolved into a functionality that 
>>> I believe is far more beneficial to Swift, and subsequently should be the 
>>> focus of its own proposal. So here is the improved (pre-)proposal:
>>> 
>>> # Factory Initializers
>>> 
>>> The "factory" pattern is common in many languages, including Objective-C. 
>>> Essentially, instead of initializing a type directly, a method is called 
>>> that returns an instance of the appropriate type determined by the input 
>>> parameters. Functionally this works well, but ultimately it forces the 
>>> client of the API to remember to call the factory method instead, rather 
>>> than the type's initializer. This might seem like a minor gripe, but given 
>>> that we want Swift to be as approachable as possible to new developers, I 
>>> think we can do better in this regard.
>>> 
>>> Rather than have a separate factory method, I propose we build the factory 
>>> pattern right into Swift, by way of specialized “factory initializers”. The 
>>> exact syntax was proposed by Philippe Hausler from the previous thread, and 
>>> I think it is an excellent solution:
>>> 
>>> class AbstractBase {
>>>  public factory init(type: InformationToSwitchOn) {
>>>  return ConcreteImplementation(type)
>>>  }
>>> }
>>> 
>>> class ConcreteImplementation : AbstractBase {
>>> 
>>> }
>>> 
>>> Why exactly would this be useful in practice? In my own development, I’ve 
>>> come across a few places where this would especially be relevant:
>>> 
>>> ## Class Cluster/Abstract Classes
>>> This was the reasoning behind the original proposal, and I still think it 
>>> would be a very valid use case. The public superclass would declare all the 
>>> public methods, and could delegate off the specific implementations to the 
>>> private subclasses. Alternatively, this method could be used as an easy way 
>>> to handle backwards-compatibility: rather than litter the code with 
>>> branches depending on the OS version, simply return the OS-appropriate 
>>> subclass from the factory initializer. Very useful.
>>> 
>>> ## Protocol Initializers
>>> Proposed by Brent Royal-Gordon, we could use factory initializers with 
>>> protocol extensions to return the appropriate instance conforming to a 
>>> protocol for the given needs. Similar to the class cluster/abstract class 
>>> method, but can work with structs too. This would be closer to the factory 
>>> method pattern, since you don’t need to kn

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

[Riley Testut via swift-evolution]

FWIW, I'm still against this proposal, but since it will be accepted 
regardless, here are my thoughts:

• Open keyword is significantly better. 
• Members should be *open* by default, and final should be opt-in. If you're 
opening up a class for subclassing, my gut says you should allow the client to 
do as they wish. If only one or two methods should be overridable, I think 
delegation (via protocols) is a much better solution.
• I feel like final and open are now *almost* on the same axis, but not quite; 
open controls subclassability outside module, but final controls it for both. 
Why not use access control modifiers, such as:

- public(open)
- internal(open) (default)
- fileprivate(open)
- private(open) = final

Then, we could remove the "final" keyword from the language completely, and use 
access control as normal. I feel like this unifies everything much better 
(private(open) does seem a little weird though).

On Jul 15, 2016, at 1:27 AM, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Jul 14, 2016, at 2:39 PM, Chris Lattner  wrote:
>> 
>> asks the community for an in-depth discussion of the secondary points of the 
>> proposal: does it make sense to require every member to be marked as 
>> “overridable” in order to be overridden by an open subclass outside of the 
>> current module?
> 
> To be clear: You want this discussion to happen in the next review thread, 
> rather than in this thread?
> 
> -- 
> 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] [Discussion] Rename BitwiseOperations protocol

[Riley Testut via swift-evolution]

Wasn't there a proposal to stop defining methods in addition to global 
operators? I would very much support that, doesn't make sense to me to have two 
ways to do the same thing IMO.

> On Jul 3, 2016, at 3:40 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Jul 3, 2016, at 9:41 AM, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> 
>> I am still curious why the SE-0104 FixedWidthInteger protocol uses member 
>> functions like “.xor” rather than operators for bitwise manipulation.
> 
> The global operators are implemented in terms of those methods in the 
> protocol.
> 
> -Chris
> 
>> 
>> Nevin
>> 
>>> On Fri, Jul 1, 2016 at 8:19 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Fri Jul 01 2016, Riley Testut  wrote:
>>> 
>>> > Hi all,
>>> >
>>> > This is probably very minor, but I’m not sure the protocol name
>>> > “BitwiseOperations” fits the Swift API Design Guidelines. Here’s what
>>> > the guidelines have to say about protocol names:
>>> >
>>> > Protocols that describe what something is should read as nouns (e.g. 
>>> > Collection).
>>> >
>>> > Protocols that describe a capability should be named using the
>>> > suffixes able, ible, or ing (e.g. Equatable, ProgressReporting).
>>> >
>>> > From these two, BitwiseOperations appears to be (attempting) to follow
>>> > the first rule, yet “BitwiseOperations” doesn’t really describe what
>>> > the type is, but rather that it can do bitwise operations. The
>>> > documentation itself even describes the protocol as “a type that
>>> > supports standard bitwise arithmetic operators."
>>> >
>>> > I propose we rename it to “BitwiseOperable”, or something
>>> > similar. Again, a small change, but if this were to ever happen, I
>>> > think Swift 3 is the time.
>>> 
>>> BitwiseOperations should really be retired after
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>>> is implemented, and its uses replaced by FixedWidthInteger.
>>> 
>>> --
>>> 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
> 
> ___
> 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-0115: Rename Literal Syntax Protocols

[Riley Testut via swift-evolution]

> When naming, we need to learn to stop treating the comfortable ring of
> familiar word patterns as an arbiter of success.

I’m not sure I agree with this statement. I would argue we should most 
certainly aim to keep a consistent feel across our naming conventions, and 
furthermore, I think familiar word patterns greatly lowers barrier for entry 
for newcomers to the language. A big reason for so many of these renamings is 
because they don’t feel “Swifty”, and even if that might not be a good 
technical reason, I think it’s as valid a reason as any.

Following that, “ExpressibleAsIntegerLiteral” feels extremely un-swifty, and 
while technically you could argue it follows the Swift API Guidelines, the fact 
that it’s the only protocol with the adjective at the beginning and not the end 
is a giant red flag to me (unless I’m missing some).

A final thought: is it really better to have a technically correct name over 
one that, while technically incorrect, got its point across about how it should 
be used? This might just be me, but I would far prefer a name that from my 
interpretation would tell me how to use it, rather than one that would require 
me to think about what it actually means (as we’ve seen from all the confusion 
about what these protocols were actually doing).

Overall though, I’m glad there is this much debate about the future of these 
names, I think it will leave us with the best name (eventually) :-)

> On Jul 2, 2016, at 2:53 PM, Dave Abrahams  wrote:
> 
> 
> on Sat Jul 02 2016, Riley Testut  > wrote:
> 
>> (My bad, accidentally hit send too early). 
>> 
>> That, or we could keep either the Convert or Express forms with
>> "IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we
>> decide "express" really is the best word to describe what happens, I
>> personally prefer "IntegerLiteralExpressing" to
>> "ExpressibleAsIntegerLiteral", which doesn't feel at home with the
>> other Swift protocol names.
> 
> It doesn't matter if it “feels at home” if it has the wrong meaning.
> It's not that Integer can express an integer literal; It's that an
> integer literal can express an Integer.
> 
> When naming, we need to learn to stop treating the comfortable ring of
> familiar word patterns as an arbiter of success.
> 
>> 
>> Riley
>> 
>>> On Jul 2, 2016, at 10:49 AM, Riley Testut  wrote:
>>> 
>>> I kinda agree that these names still aren't the best. FWIW, I much
>>> preferred the originals, even if they could be misleading.
>>> 
>>> What if we changed the names to be verbs instead of adjectives? Something 
>>> like "IntegerLiteralTransforming"?
>>> 
 On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution 
  wrote:
 
 
> on Sat Jul 02 2016, Anton Zhilin  wrote:
> 
> -1 from me. I suggest to wait until we get generic protocols
> in Swift 4, then we can use the following:
> 
> protocol From {
>  init(_ from: T)
> }
> 
> And deprecate all the weird Convertibles.
 
 Even if we could do that, “From” would never be an appropriate name for
 the ability to express a type as a particular kind of literal.
 
 -- 
 -Dave
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> -- 
> -Dave

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

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

[Riley Testut via swift-evolution]

(My bad, accidentally hit send too early). 

That, or we could keep either the Convert or Express forms with 
"IntegerLiteralConverting" or "IntegerLiteralExpressing". And if we decide 
"express" really is the best word to describe what happens, I personally prefer 
"IntegerLiteralExpressing" to "ExpressibleAsIntegerLiteral", which doesn't feel 
at home with the other Swift protocol names.

Riley

> On Jul 2, 2016, at 10:49 AM, Riley Testut  wrote:
> 
> I kinda agree that these names still aren't the best. FWIW, I much preferred 
> the originals, even if they could be misleading.
> 
> What if we changed the names to be verbs instead of adjectives? Something 
> like "IntegerLiteralTransforming"?
> 
>> On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> 
>>> on Sat Jul 02 2016, Anton Zhilin  wrote:
>>> 
>>> -1 from me. I suggest to wait until we get generic protocols
>>> in Swift 4, then we can use the following:
>>> 
>>> protocol From {
>>>   init(_ from: T)
>>> }
>>> 
>>> And deprecate all the weird Convertibles.
>> 
>> Even if we could do that, “From” would never be an appropriate name for
>> the ability to express a type as a particular kind of literal.
>> 
>> -- 
>> -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] [Review] SE-0115: Rename Literal Syntax Protocols

[Riley Testut via swift-evolution]

I kinda agree that these names still aren't the best. FWIW, I much preferred 
the originals, even if they could be misleading.

What if we changed the names to be verbs instead of adjectives? Something like 
"IntegerLiteralTransforming"?

> On Jul 2, 2016, at 10:35 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
>> on Sat Jul 02 2016, Anton Zhilin  wrote:
>> 
>> -1 from me. I suggest to wait until we get generic protocols
>> in Swift 4, then we can use the following:
>> 
>> protocol From {
>>init(_ from: T)
>> }
>> 
>> And deprecate all the weird Convertibles.
> 
> Even if we could do that, “From” would never be an appropriate name for
> the ability to express a type as a particular kind of literal.
> 
> -- 
> -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

[swift-evolution] [discussion] Fixing Protocols with Self or Associated Type Requirements

[Riley Testut via swift-evolution]

Hello all,

If you’ve been (attempting) protocol-oriented development in your own projects, 
I’m sure you’ve come across a particular build error at one point:

> Protocol ‘MyProtocol' can only be used as a generic constraint because it has 
> Self or associated type requirements

To be frank, this restriction in the current Swift model sucks, a lot. In 
*many* cases, this prevents me from using protocols, and instead I have to fall 
back to using concrete types.

Here are a couple examples of using protocols with collections that should work 
fine, but simply don’t:

A Set of Types Conforming to Protocol

protocol MyProtocol: Hashable {}

let set = Set() // ERROR: Protocol ‘MyProtocol' can only be used as 
a generic constraint because it has Self or associated type requirements

When declaring a Set, the generic type of the Set’s contents must conform to 
Hashable. Following this, it would appear that you should be able to declare a 
Set containing types conforming to a given protocol which in turn conforms to 
Hashable. Nope! This also means you can’t have a Set (so no 
type-erased Sets for you!). One potential workaround is to use a box type, but 
if exposing the set to a user, this is essentially a leaky abstraction.

Finding a Protocol Type Instance in an Array

protocol MyProtocol {}
struct MyStruct: MyProtocol {}

var array = [MyProtocol]()
array.append(MyStruct())

let index = array.index(of: MyStruct()) // ERROR: Cannot invoke 'index' with an 
argument list of type '(of: MyStruct)'

So, we can’t use Set as a collection for our protocol types, let’s use Array 
instead! Not so fast: because MyProtocol doesn’t conform to Equatable, we can’t 
use the Array.index(of:) function to find it. Easy fix though, just make 
MyProtocol conform to Equatable, right?

protocol MyProtocol: Equatable {}
struct MyStruct: MyProtocol {}

var array = [MyProtocol]() // ERROR: Protocol ‘MyProtocol' can only be used as 
a generic constraint because it has Self or associated type requirements

Nope! Now that it conforms to Equatable, it can no longer be used in Array’s 
type declaration. However, there is a (somewhat) workaround for this problem:

protocol MyProtocol {}
func ==(lhs: MyProtocol, rhs: MyProtocol) -> Bool { return true }

struct MyStruct: MyProtocol {}

var array = [MyProtocol]()
array.append(MyStruct())

let index = array.index(where: { $0 == MyStruct() })

Basically, we can define the == function for MyProtocol, and then instead of 
using Array.index(of:), we use Array.index(where:) to manually compare each 
item to see if it matches, aka what Array.index(of:) would do for us normally 
if we simply could declare MyProtocol as conforming to equatable.

TL;DR
Swift really pushes the idea of protocol-oriented programming, and for the most 
part this works well. However, due to some underlying restrictions in the 
current Swift model, you can’t use protocols in all the same places you can use 
concrete types, which sucks. This is especially confusing for beginners who are 
trying to use protocols, but get frustrated when it doesn’t work where they 
want it to (and don’t understand why), so they fall back to using concrete 
types (usually implemented with class inheritance). For this reason, I think 
these restrictions need to be fixed ASAP, or else the Swift language is 
essentially pushing people away from protocol-oriented programming.

Riley Testut

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

Re: [swift-evolution] [Proposal draft] NSError bridging

[Riley Testut via swift-evolution]

Love the proposal overall, but not sure about the CustomNSError name either. It 
doesn’t seem to read like a Swift protocol name.
 
Somewhat related, is there a reason these protocols don’t contain the 
“Protocol” suffix? Stands in stark contrast with the rest of the Swift protocol 
naming conventions (AFAIK).

> On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Obviously, I’m in favor of this one. +1!
>> 
>> I think I did prefer the older name of CustomUserInfoError for the 
>> domain/code/userInfo protocol, rather than CustomNSError. This is just 
>> because I’d like to be able to do a global search through my project for 
>> “NSError” and have it turn up empty. Maybe a silly reason, I know. ;-)
> 
> 
> I’m floating CustomNSError as the protocol name because I don’t feel that 
> domain, core, or userInfo are fundamental to the Swift error model—they’re 
> about exposing things specifically to NSError.
> 
>   - 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] [Proposal] Protected Access Level

[Riley Testut via swift-evolution]

Unless I'm missing something Brent, your suggestions still wouldn't allow the 
developer to provide a public class in a module designed to be subclassed by 
clients in another module and access these "private" details, which is a real 
problem I'm having in my current project.

I have a framework which provides an abstract model object designed to be 
subclassed (and yes it has to be a class and not a struct for a multitude of 
reasons ) by clients of the framework. There are several convenience methods + 
properties I have exposed for subclasses to use, but they should really be 
implementation details; a client using these model objects should not have to 
know about them. Even worse, several of the properties are mutable so the 
subclasses can modify them, but they certainly should *not* be modified by 
anything else.

Right now, I'm limited to simply commenting something akin to "DO NOT CALL" 
next to these methods/properties, which definitely goes against Swift's safety 
focus. For these reasons, I'm 100% in support of a protected access control 
modifier.

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> To begin with, I'm not a fan of `protected` access. But even leaving that 
> aside, I have a few questions and critiques.
> 
>> A common case is the UIView from UIKit. Many developers are tempted to make 
>> this call:
>> 
>> view.layoutSubviews()
>> The documentation says: "You should not call this method directly. If you 
>> want to force a layout update, call the setNeedsLayoutmethod instead to do 
>> so prior to the next drawing update. If you want to update the layout of 
>> your views immediately, call the layoutIfNeeded method."
> 
> This example is illuminating in several ways.
> 
> * The rule is not simply that "only the class should call 
> `layoutSubviews()`"; it is effectively "*you* should never call 
> `layoutSubviews()` except when `super`ing up from your override". Calling 
> `layoutSubviews()` from `insertRows(at:)` is just as much a mistake if 
> `insertRows(at:)` is part of the class as if it is not. So isn't `protected` 
> insufficiently strict to properly serve this use case?
> 
> * At the same time, something outside `layoutSubviews()` has to be able to 
> call `layoutSubviews()`. In the case of UIKit, though, that "something" is 
> always within UIKit itself, never outside it. So should `protected` have a 
> "bottom", a level below which calls are unrestricted? For instance, in 
> UIKit's case you might have `protected fileprivate`, meaning "anything up to 
> `fileprivate` has unrestricted use; anything above that can override and 
> `super` up from its override, but not use it any other way".
> 
>protected fileprivate func layoutSubviews()
> 
> * `layoutSubviews()` is also something you should probably always `super` up 
> to. Have you considered addressing `super` requirements at all?
> 
> In short, is a traditional `protected` really the feature you want to handle 
> this use case, or would a very different design actually suit it a lot better?
> 
>> When declarated by a class the protected member will be visible to the class 
>> itself and all the derived classes.
> 
> In what scope? The same as the class?
> 
> Is there not room for, for instance, "usable without restriction in this 
> file, override-only in the rest of this module, invisible outside it"? For 
> instance, `internal(protected) fileprivate`, or perhaps `internal(override) 
> fileprivate`? `layoutSubviews()` might then be `public(override) 
> fileprivate`—the ability to override is public, the ability to use it 
> unrestricted is filewide.
> 
>public(override) fileprivate func layoutSubviews()
>internal(override) fileprivate func privateSubclassingHook()
> 
>> public protected(set) var x = 20
> 
> Of course, that might be difficult to combine with the `(set)` syntax. 
> `public(set: override)`, maybe? With, for instance, `public internal(set: 
> override) private(set)` if you want the property's getter public and its 
> setter overridable internally and callable in private scope.
> 
>public(override) fileprivate func layoutSubviews()
>internal(override) fileprivate func privateSubclassingHook()
>public(get, set: override) internal(set) var x = 20
> 
> But there's something about this that's starting to seem a little rotten. I 
> think the problem is that we're not really trying to widen the ability to 
> override, we're trying to restrict the ability to call. Let's try 
> restructuring along those lines:
> 
>public fileprivate(call) func layoutSubviews()
>internal fileprivate(call) func privateSubclassingHook()
>public internal(set: call) var x = 20
> 
> That seems much cleaner to me.
> 
>> If the member is declared as final then it will be visible but not can be 
>> overrided by the derived classes. Just like it works with other access 
>> levels.
> 
> With the "overridable but otherwise unusable" conception 

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

[Riley Testut via swift-evolution]

100% in favor of this proposal. IMO, Foundation should feel as natural to use 
as the Swift standard library; providing native Swift value types to represent 
many Foundation objects certainly brings us much closer to accomplishing that 
goal. 

My only concern is that the Swift wrappers should always be just as "powerful" 
as their underlying Foundation type. That is, the only reason to use NSData 
over Data, for example, is because you want a reference type; you should never 
have to use the NS types directly for a certain feature. However, based off the 
proposal this seems like it will be the case.

So yes, a giant +1 to this.

> On Apr 25, 2016, at 10:27 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0069: Mutability and Foundation Value Types" begins now and 
> runs through May 4. The proposal is available here:
> 
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.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, eventually, determine 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 you 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] Mutability for Foundation types in Swift

[Riley Testut via swift-evolution]

Very happy to see this proposal; felt strange that for a language so focused on 
value-types an entire framework open sourced with the language was composed 
entirely of reference-types (albeit for obvious reasons). So +1 for that.

One particular section that caught my interest was this:
> The most obvious drawback to using a struct is that the type can no longer be 
> subclassed. At first glance, this would seem to prevent the customization of 
> behavior of these types. However, by publicizing the reference type and 
> providing a mechanism to wrap it (mySubclassInstance as ValueType), we enable 
> subclasses to provide customized behavior.

I'm incredibly biased, but I recently proposed and submitted a pull request 
that would introduce "factory initializers" to the language 
(https://github.com/apple/swift-evolution/pull/247). The full proposal has more 
info, but essentially factory initializers would allow for directly returning 
initialized types from designated factory initializers, similar to how 
initializers are implemented in Objective-C.

Anyway, I feel the Factory Initializer proposal would work very well with this 
Foundation proposal. While I believe the current suggestion of casting the 
reference type as the value type works well, I don't believe it is necessarily 
the client of the API's job to use it; I believe it would make far more sense 
for there to be an extension adding additional factory initializers to the 
class, which would determine the underlying reference type to use based on the 
input parameters.

For example, here is the example of using a custom subclass for the Data type 
mentioned in this Foundation proposal:
> /// Create a Data with a custom backing reference type.
> class MyData : NSData { }
> let dataReference = MyData()
> let dataValue = dataReference as Data // dataValue copies dataReference

I personally would rather see something akin to this:

public extension Data {
factory init(inputData: ...)
{
if ... {
// Return subclass best suited for storing this 
particular input data
return MyData(inputData) as Data
}
else {
let data = NSData()

/* OMITTED: add hypothetical inputData to NSData 
depending on what it is */

return data 
}

This means the client of the API never has to worry about which subclass is 
best suited for them; everything would "just work". This also better mimics the 
existing class cluster pattern in Foundation, which might help with this 
transition should my proposal be accepted.

Regardless though, very happy to see this being pushed forward. Just thought 
I'd suggest ways to make this proposal (hopefully) easier to both implement and 
use :)

> On Apr 22, 2016, at 12:52 PM, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi David,
> 
>> On Apr 22, 2016, at 12:13 PM, David Waite  
>> wrote:
>> 
>> Amazing, I am really looking forward to this feature!
>> 
>> Comments:
>> 
>> - For Locale and Calendar, one possible Swift layout would be to synthesize 
>> a protocol and to use that to represent bridged API. You could then bridge 
>> inbound to either the immutable value type or the dynamic class-based type. 
>> On the swift side, these are constructed as two distinct types.
> 
> That’s an interesting approach, I’ll consider that for these.
> 
>> 
>> - For any of these types, are there improvements (similar to String) which 
>> would be worth making before exposing ’the’ Swift type and API? The ones I’m 
>> specifically worried about are Date and URL, since I’ve seen so many 
>> standard language time and networking API show their age over time.
>> 
>> -DW
> 
> We’re absolutely going to be making Swift-specific improvements to many of 
> these types. I think the resulting API is better in many ways. For example, 
> on URL the main improvement is that the resource values dictionary is now 
> struct type with a lot of strongly-typed properties. It’s still got a lot of 
> optionals because of the way that the underlying fetch works, but it’s 
> better. Date gains mutating methods along with support for operators like += 
> and < >. 
> 
> One of the guiding principles of our effort was evolution over revolution. 
> Foundation is obviously used in tons and tons of API. We want to maintain 
> conceptual compatibility with the entire OS X / iOS / watchOS / tvOS SDK when 
> it is imported into Swift. Hopefully this also means that converting from 
> reference to value types in your own uses of these API does not require a 
> complete rethink of how you use them, but still provide the benefits outlined 
> in the proposal. We’ll continue to iterate and improve over time.
> 
> Thanks,
> 
> - Tony
> 
>>  
>>> On Apr 22, 2016, at 11:18 AM, Tony Parker via swift-evolution 
>>>  wrote:

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

gt; wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Yes and No.
>>>>>>>>>>> Yes, because this is a problem I run into all the time, and I 
>>>>>>>>>>> really want swift to have a solution for it. I especially like 
>>>>>>>>>>> Brent’s idea of a protocol init.
>>>>>>>>>>> No, because I have gotten a bit greedy. I want us to take a step 
>>>>>>>>>>> back and look at the underlying problem to see if we can come up 
>>>>>>>>>>> with something which completely solves it… and I think factories 
>>>>>>>>>>> get us only part way there. Let’s take a moment and see if we can 
>>>>>>>>>>> create something uniquely swift before we copy/paste existing 
>>>>>>>>>>> solutions.
>>>>>>>>>>> Think about Cocoa’s class clusters for a moment. I love them, but 
>>>>>>>>>>> they are a pain to subclass. To the level where any beginning Cocoa 
>>>>>>>>>>> instruction tells you explicitly not to subclass them. Similarly, 
>>>>>>>>>>> even in my own factories, they are always a pain to extend.
>>>>>>>>>>> I want our factory inits to be extensible by default.
>>>>>>>>>>> 
>>>>>>>>>>> By extensible, I mean that I want to be able to add a new subclass 
>>>>>>>>>>> (or a new entity satisfying a protocol), and have it come out of 
>>>>>>>>>>> the factory when appropriate without editing the base class! 
>>>>>>>>>>> Madness, I know, but:
>>>>>>>>>>> 1) I may not have access to the source of the base class (e.g. 
>>>>>>>>>>> Cocoa Collections)
>>>>>>>>>>> 2) I always feel a bit dirty giving the base class knowledge of 
>>>>>>>>>>> it’s subclasses
>>>>>>>>>>> 3) It is a royal pain, and a potential source of errors as things 
>>>>>>>>>>> get refactored when adding new subclasses
>>>>>>>>>>> 
>>>>>>>>>>> I think I have at least the seed of an idea of how to solve this, 
>>>>>>>>>>> and I am hoping that one of you (who are all much smarter than I) 
>>>>>>>>>>> might have the key to getting it the rest of the way.
>>>>>>>>>>> I ran into this problem again last week, and it made me think of an 
>>>>>>>>>>> old language I used to use...
>>>>>>>>>>> There was a small programming language I used to use in the 90’s 
>>>>>>>>>>> which had an interesting core language feature we called 
>>>>>>>>>>> “handlers”. These were a lot like registering for notifications, 
>>>>>>>>>>> except that writing a function (with a special “Handler” attribute: 
>>>>>>>>>>> “Handler func myFuncName()") was all you needed to do to register. 
>>>>>>>>>>> Writing “Handle myFuncName()” would then systematically call every 
>>>>>>>>>>> function with that name and the Handler attribute.
>>>>>>>>>>> That is, instead of calling a single function, it would 
>>>>>>>>>>> systematically call a series of functions (all with the same name).
>>>>>>>>>>> There was one other thing that made these handlers special. Each 
>>>>>>>>>>> one had the option, when it was called, to reply that it was the 
>>>>>>>>>>> one true handler, and the others didn’t need to be called. 
>>>>>>>>>>> Basically, it said “I've got this!”. This even allowed it to return 
>>>>>>>>>>> a result to the caller.
>>>>>>>>>>> The original intent of this feature (and why it was a core language 
>>>>>>>>>>> feature) was to handle events. It would handle things like hit 
>>>>>>>>>>> testing and key events fairly elegantly. It was a powerful feature, 
>>>>>>>

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

, even 
>>>>>>> in my own factories, they are always a pain to extend.
>>>>>>> I want our factory inits to be extensible by default.
>>>>>>> 
>>>>>>> By extensible, I mean that I want to be able to add a new subclass (or 
>>>>>>> a new entity satisfying a protocol), and have it come out of the 
>>>>>>> factory when appropriate without editing the base class! Madness, I 
>>>>>>> know, but:
>>>>>>> 1) I may not have access to the source of the base class (e.g. Cocoa 
>>>>>>> Collections)
>>>>>>> 2) I always feel a bit dirty giving the base class knowledge of it’s 
>>>>>>> subclasses
>>>>>>> 3) It is a royal pain, and a potential source of errors as things get 
>>>>>>> refactored when adding new subclasses
>>>>>>> 
>>>>>>> I think I have at least the seed of an idea of how to solve this, and I 
>>>>>>> am hoping that one of you (who are all much smarter than I) might have 
>>>>>>> the key to getting it the rest of the way.
>>>>>>> I ran into this problem again last week, and it made me think of an old 
>>>>>>> language I used to use...
>>>>>>> There was a small programming language I used to use in the 90’s which 
>>>>>>> had an interesting core language feature we called “handlers”. These 
>>>>>>> were a lot like registering for notifications, except that writing a 
>>>>>>> function (with a special “Handler” attribute: “Handler func 
>>>>>>> myFuncName()") was all you needed to do to register. Writing “Handle 
>>>>>>> myFuncName()” would then systematically call every function with that 
>>>>>>> name and the Handler attribute.
>>>>>>> That is, instead of calling a single function, it would systematically 
>>>>>>> call a series of functions (all with the same name).
>>>>>>> There was one other thing that made these handlers special. Each one 
>>>>>>> had the option, when it was called, to reply that it was the one true 
>>>>>>> handler, and the others didn’t need to be called. Basically, it said 
>>>>>>> “I've got this!”. This even allowed it to return a result to the caller.
>>>>>>> The original intent of this feature (and why it was a core language 
>>>>>>> feature) was to handle events. It would handle things like hit testing 
>>>>>>> and key events fairly elegantly. It was a powerful feature, so it was 
>>>>>>> quickly used for other things. It made things like plug-ins 
>>>>>>> ridiculously simple. We even used it for a form of error handling.
>>>>>>> I remember helping to write a page layout program in it, and we used 
>>>>>>> handlers not just for the hit testing, but for the tool palette as 
>>>>>>> well. The end result was that you were able to add new shapes and new 
>>>>>>> tools without modifying existing code at all. It is a feature I miss 
>>>>>>> all the time...
>>>>>>> 
>>>>>>> That is more power than we need here, but it provided me the 
>>>>>>> inspiration for a potential solution to the factory problem. Back to 
>>>>>>> swift…
>>>>>>> 
>>>>>>> The idea here is to give each interested subclass a chance to say “I've 
>>>>>>> got this!”. The factory init runs through each of the subclasses’ 
>>>>>>> overrides until it finds one that doesn’t return nil. New subclasses 
>>>>>>> can be added and they will be given a chance as well (without modifying 
>>>>>>> the base class). The first subclass to successfully init wins. (only 
>>>>>>> subclasses which override the factory init would be considered)
>>>>>>> 
>>>>>>> class AbstractBase {
>>>>>>> public factory init?(type: InformationToSwitchOn){
>>>>>>> //I like having an explicit call, so that the traditional 
>>>>>>> (non-distributed) factory is possible as well
>>>>>>> return factory.init(type) //We could also call this 
>>>>>>> “subclass.init(type)” to mirror super
>>>>>

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

h each of the subclasses’ 
>>>>> overrides until it finds one that doesn’t return nil. New subclasses can 
>>>>> be added and they will be given a chance as well (without modifying the 
>>>>> base class). The first subclass to successfully init wins. (only 
>>>>> subclasses which override the factory init would be considered)
>>>>> 
>>>>> class AbstractBase {
>>>>> public factory init?(type: InformationToSwitchOn){
>>>>> //I like having an explicit call, so that the traditional 
>>>>> (non-distributed) factory is possible as well
>>>>> return factory.init(type) //We could also call this 
>>>>> “subclass.init(type)” to mirror super
>>>>> }
>>>>> }
>>>>> class ConcreteImplementation : AbstractBase {
>>>>> public factory override init?(type: InformationToSwitchOn){
>>>>> guard type == compatibleWithThisType else {return nil} //If info 
>>>>> doesn’t work for us, we return nil, and the next class gets a shot
>>>>>   //Init concrete type here
>>>>> }
>>>>> }
>>>>> 
>>>>> The main issue which still needs to be solved is that the order they get 
>>>>> called sometimes really matters (this was solved by a well defined 
>>>>> ordering + IDE features in the language mentioned above). For the most 
>>>>> part, as long as subclasses are called before their superclasses (or 
>>>>> there is a some method for cascading), it works. There are still times 
>>>>> where you want to define a specific ordering though (e.g. a new subclass 
>>>>> wants to get called before an existing subclasses to override some of 
>>>>> it’s use cases).
>>>>> I see a few options (and I would love to hear more):
>>>>> - subclasses define a numeric precedence (similar to operators now). This 
>>>>> is probably the most effective stop-gap solution, but is not elegant.
>>>>> - subclasses do whatever we change operator precedence to do in the future
>>>>> - optionally allow subclasses to name another specific subclass that they 
>>>>> are before/after
>>>>> - allow subclasses to declare that they would like to be earlier or later 
>>>>> (or that they don’t care) in the calling list. subclasses defined outside 
>>>>> of the module where the base class was defined would be placed more 
>>>>> extremely early/late. Exact order is undefined, but rough ordering is 
>>>>> possible.
>>>>> - return (to the superclass) an array of all subclasses which 
>>>>> successfully inited. It can then select which one it wants and return it. 
>>>>> This seems overly inefficient to me, since you are initializing a bunch 
>>>>> of unused objects.
>>>>> - 
>>>>> 
>>>>> The end result is that you can extend factories of both classes and 
>>>>> protocols without access to the original source code.  
>>>>> 
>>>>> I also don’t think that the base should always need to be abstract. 
>>>>> Factory inits should allow returning subclasses as a way of replacing 
>>>>> themselves with a subclass, and returning nil if they are failable, but 
>>>>> if there is no return (or return self), it can create an instance of 
>>>>> itself. This way, it provides a customization point where subclasses can 
>>>>> handle special cases, but the class itself provides an obvious default 
>>>>> (i.e. a much less messy form of class cluster).
>>>>> 
>>>>> class Base {
>>>>> public factory init(type: InformationToSwitchOn){
>>>>>   if let subclass = factory.init(type){
>>>>>   return subclass
>>>>>   }
>>>>>   return self.init()//If subclasses didn’t work, initialize ourselves
>>>>> }
>>>>> }
>>>>> 
>>>>> Thoughts?  Too crazy to consider?
>>>>> 
>>>>> Thanks,
>>>>> Jon
>>>>> 
>>>>> On Feb 8, 2016, at 11:26 AM, Charles Srstka >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>> wrote:
>>>>> 
>>>>> >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>>>>> >> >>>> >> <https

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

gt;>> the option, when it was called, to reply that it was the one true handler, 
>>> and the others didn’t need to be called. Basically, it said “I've got 
>>> this!”. This even allowed it to return a result to the caller.
>>> The original intent of this feature (and why it was a core language 
>>> feature) was to handle events. It would handle things like hit testing and 
>>> key events fairly elegantly. It was a powerful feature, so it was quickly 
>>> used for other things. It made things like plug-ins ridiculously simple. We 
>>> even used it for a form of error handling.
>>> I remember helping to write a page layout program in it, and we used 
>>> handlers not just for the hit testing, but for the tool palette as well. 
>>> The end result was that you were able to add new shapes and new tools 
>>> without modifying existing code at all. It is a feature I miss all the 
>>> time...
>>> 
>>> That is more power than we need here, but it provided me the inspiration 
>>> for a potential solution to the factory problem. Back to swift…
>>> 
>>> The idea here is to give each interested subclass a chance to say “I've got 
>>> this!”. The factory init runs through each of the subclasses’ overrides 
>>> until it finds one that doesn’t return nil. New subclasses can be added and 
>>> they will be given a chance as well (without modifying the base class). The 
>>> first subclass to successfully init wins. (only subclasses which override 
>>> the factory init would be considered)
>>> 
>>> class AbstractBase {
>>> public factory init?(type: InformationToSwitchOn){
>>> //I like having an explicit call, so that the traditional 
>>> (non-distributed) factory is possible as well
>>> return factory.init(type) //We could also call this 
>>> “subclass.init(type)” to mirror super
>>> }
>>> }
>>> class ConcreteImplementation : AbstractBase {
>>> public factory override init?(type: InformationToSwitchOn){
>>> guard type == compatibleWithThisType else {return nil} //If info 
>>> doesn’t work for us, we return nil, and the next class gets a shot
>>> //Init concrete type here
>>> }
>>> }
>>> 
>>> The main issue which still needs to be solved is that the order they get 
>>> called sometimes really matters (this was solved by a well defined ordering 
>>> + IDE features in the language mentioned above). For the most part, as long 
>>> as subclasses are called before their superclasses (or there is a some 
>>> method for cascading), it works. There are still times where you want to 
>>> define a specific ordering though (e.g. a new subclass wants to get called 
>>> before an existing subclasses to override some of it’s use cases).
>>> I see a few options (and I would love to hear more):
>>> - subclasses define a numeric precedence (similar to operators now). This 
>>> is probably the most effective stop-gap solution, but is not elegant.
>>> - subclasses do whatever we change operator precedence to do in the future
>>> - optionally allow subclasses to name another specific subclass that they 
>>> are before/after
>>> - allow subclasses to declare that they would like to be earlier or later 
>>> (or that they don’t care) in the calling list. subclasses defined outside 
>>> of the module where the base class was defined would be placed more 
>>> extremely early/late. Exact order is undefined, but rough ordering is 
>>> possible.
>>> - return (to the superclass) an array of all subclasses which successfully 
>>> inited. It can then select which one it wants and return it. This seems 
>>> overly inefficient to me, since you are initializing a bunch of unused 
>>> objects.
>>> - 
>>> 
>>> The end result is that you can extend factories of both classes and 
>>> protocols without access to the original source code.  
>>> 
>>> I also don’t think that the base should always need to be abstract. Factory 
>>> inits should allow returning subclasses as a way of replacing themselves 
>>> with a subclass, and returning nil if they are failable, but if there is no 
>>> return (or return self), it can create an instance of itself. This way, it 
>>> provides a customization point where subclasses can handle special cases, 
>>> but the class itself provides an obvious default (i.e. a much less messy 
>>> form of class cluster).
>>> 
>>> cl

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

or the tool palette as well. The end 
> result was that you were able to add new shapes and new tools without 
> modifying existing code at all. It is a feature I miss all the time...
> 
> That is more power than we need here, but it provided me the inspiration for 
> a potential solution to the factory problem. Back to swift…
> 
> The idea here is to give each interested subclass a chance to say “I've got 
> this!”. The factory init runs through each of the subclasses’ overrides until 
> it finds one that doesn’t return nil. New subclasses can be added and they 
> will be given a chance as well (without modifying the base class). The first 
> subclass to successfully init wins. (only subclasses which override the 
> factory init would be considered)
> 
> class AbstractBase {
> public factory init?(type: InformationToSwitchOn){
> //I like having an explicit call, so that the traditional 
> (non-distributed) factory is possible as well
> return factory.init(type) //We could also call this 
> “subclass.init(type)” to mirror super
> }
> }
> class ConcreteImplementation : AbstractBase {
> public factory override init?(type: InformationToSwitchOn){
> guard type == compatibleWithThisType else {return nil} //If info 
> doesn’t work for us, we return nil, and the next class gets a shot
>   //Init concrete type here
> }
> }
> 
> The main issue which still needs to be solved is that the order they get 
> called sometimes really matters (this was solved by a well defined ordering + 
> IDE features in the language mentioned above). For the most part, as long as 
> subclasses are called before their superclasses (or there is a some method 
> for cascading), it works. There are still times where you want to define a 
> specific ordering though (e.g. a new subclass wants to get called before an 
> existing subclasses to override some of it’s use cases).
> I see a few options (and I would love to hear more):
> - subclasses define a numeric precedence (similar to operators now). This is 
> probably the most effective stop-gap solution, but is not elegant.
> - subclasses do whatever we change operator precedence to do in the future
> - optionally allow subclasses to name another specific subclass that they are 
> before/after
> - allow subclasses to declare that they would like to be earlier or later (or 
> that they don’t care) in the calling list. subclasses defined outside of the 
> module where the base class was defined would be placed more extremely 
> early/late. Exact order is undefined, but rough ordering is possible.
> - return (to the superclass) an array of all subclasses which successfully 
> inited. It can then select which one it wants and return it. This seems 
> overly inefficient to me, since you are initializing a bunch of unused 
> objects.
> - 
> 
> The end result is that you can extend factories of both classes and protocols 
> without access to the original source code.  
> 
> I also don’t think that the base should always need to be abstract. Factory 
> inits should allow returning subclasses as a way of replacing themselves with 
> a subclass, and returning nil if they are failable, but if there is no return 
> (or return self), it can create an instance of itself. This way, it provides 
> a customization point where subclasses can handle special cases, but the 
> class itself provides an obvious default (i.e. a much less messy form of 
> class cluster).
> 
> class Base {
> public factory init(type: InformationToSwitchOn){
>   if let subclass = factory.init(type){
>   return subclass
>   }
>   return self.init()//If subclasses didn’t work, initialize ourselves
> }
> }
> 
> Thoughts?  Too crazy to consider?
> 
> Thanks,
> Jon
> 
> On Feb 8, 2016, at 11:26 AM, Charles Srstka  
> wrote:
> 
> >> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
> >>  wrote:
> >> 
> >> Recently, I proposed the idea of adding the ability to implement the 
> >> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
> >> discussed it and came up with different approaches, it evolved into a 
> >> functionality that I believe is far more beneficial to Swift, and 
> >> subsequently should be the focus of its own proposal. So here is the 
> >> improved (pre-)proposal:
> >> 
> >> # Factory Initializers
> >> 
> >> The "factory" pattern is common in many languages, including Objective-C. 
> >> Essentially, instead of initializing a type directly, a method is called 
> >> that returns an instance of the appropriate type determined by the input

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

Hey all!

Very sorry, restored my MacBook at the beginning of the calendar year, and 
forgot to re-subscribe to Swift-Evolution . Once I realized this, I decided to 
hold off on pushing this forward till after Swift 2.2, and now that it's been 
released, I'd love to make moves on this!

So, is there still an interest in the proposal? If so, I'll write up a new 
proposal with everyone's feedback, and then post it here for more discussion. I 
think this would very valuable (and would certainly help a bunch in my current 
app), but want to see where everyone stands!

Riley Testut

On Feb 8, 2016, at 11:26 AM, Charles Srstka <cocoa...@charlessoft.com> wrote:

>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Recently, I proposed the idea of adding the ability to implement the "class 
>> cluster" pattern from Cocoa (Touch) in Swift. However, as we discussed it 
>> and came up with different approaches, it evolved into a functionality that 
>> I believe is far more beneficial to Swift, and subsequently should be the 
>> focus of its own proposal. So here is the improved (pre-)proposal:
>> 
>> # Factory Initializers
>> 
>> The "factory" pattern is common in many languages, including Objective-C. 
>> Essentially, instead of initializing a type directly, a method is called 
>> that returns an instance of the appropriate type determined by the input 
>> parameters. Functionally this works well, but ultimately it forces the 
>> client of the API to remember to call the factory method instead, rather 
>> than the type's initializer. This might seem like a minor gripe, but given 
>> that we want Swift to be as approachable as possible to new developers, I 
>> think we can do better in this regard.
>> 
>> Rather than have a separate factory method, I propose we build the factory 
>> pattern right into Swift, by way of specialized “factory initializers”. The 
>> exact syntax was proposed by Philippe Hausler from the previous thread, and 
>> I think it is an excellent solution:
>> 
>> class AbstractBase {
>>   public factory init(type: InformationToSwitchOn) {
>>   return ConcreteImplementation(type)
>>   }
>> }
>> 
>> class ConcreteImplementation : AbstractBase {
>> 
>> }
>> 
>> Why exactly would this be useful in practice? In my own development, I’ve 
>> come across a few places where this would especially be relevant:
>> 
>> ## Class Cluster/Abstract Classes
>> This was the reasoning behind the original proposal, and I still think it 
>> would be a very valid use case. The public superclass would declare all the 
>> public methods, and could delegate off the specific implementations to the 
>> private subclasses. Alternatively, this method could be used as an easy way 
>> to handle backwards-compatibility: rather than litter the code with branches 
>> depending on the OS version, simply return the OS-appropriate subclass from 
>> the factory initializer. Very useful.
>> 
>> ## Protocol Initializers
>> Proposed by Brent Royal-Gordon, we could use factory initializers with 
>> protocol extensions to return the appropriate instance conforming to a 
>> protocol for the given needs. Similar to the class cluster/abstract class 
>> method, but can work with structs too. This would be closer to the factory 
>> method pattern, since you don’t need to know exactly what type is returned, 
>> just the protocol it conforms to.
>> 
>> ## Initializing Storyboard-backed View Controller
>> This is more specific to Apple Frameworks, but having factory initializers 
>> could definitely help here. Currently, view controllers associated with a 
>> storyboard must be initialized from the client through a factory method on 
>> the storyboard instance (storyboard. 
>> instantiateViewControllerWithIdentifier()). This works when the entire flow 
>> of the app is storyboard based, but when a single storyboard is used to 
>> configure a one-off view controller, having to initialize through the 
>> storyboard is essentially use of private implementation details; it 
>> shouldn’t matter whether the VC was designed in code or storyboards, 
>> ultimately a single initializer should “do the right thing” (just as it does 
>> when using XIBs directly). A factory initializer for a View Controller 
>> subclass could handle the loading of the storyboard and returning the 
>> appropriate view controller.
>> 
>> Here are some comments from the previous thread that I believe are still 
>> relevant:
>> 
>> 
&

Re: [swift-evolution] [Proposal] Factory Initializers

[Riley Testut via swift-evolution]

Glad to see there's definitely some interest in this community then! I would 
love to start writing up a final proposal to submit to the Swift-Evolution 
repo, but I think that last piece of information needed would be the actual 
method of initialization, specifically should we allow for returning instances 
from convenience initializers, or should we simply assign to self? 

Personally, I think returning from the initializer makes the most sense, 
especially because "self" in a protocol extension seems ambiguous. However, I'm 
not that much in favor that I couldn't be convinced to simply assign to self, 
because that already has some low level support in the language. Anyone have 
strong thoughts one way or another?

> On Dec 22, 2015, at 1:00 PM, Charles Srstka <cocoa...@charlessoft.com> wrote:
> 
> Strong +1 on this, particularly on the part about protocol initializers. This 
> would bring together some of the best aspects of both Objective-C class 
> clusters and Swift protocol-oriented programming and would be a huge benefit 
> to application developers.
> 
> Charles
> 
>> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> Recently, I proposed the idea of adding the ability to implement the "class 
>> cluster" pattern from Cocoa (Touch) in Swift. However, as we discussed it 
>> and came up with different approaches, it evolved into a functionality that 
>> I believe is far more beneficial to Swift, and subsequently should be the 
>> focus of its own proposal. So here is the improved (pre-)proposal:
>> 
>> # Factory Initializers
>> 
>> The "factory" pattern is common in many languages, including Objective-C. 
>> Essentially, instead of initializing a type directly, a method is called 
>> that returns an instance of the appropriate type determined by the input 
>> parameters. Functionally this works well, but ultimately it forces the 
>> client of the API to remember to call the factory method instead, rather 
>> than the type's initializer. This might seem like a minor gripe, but given 
>> that we want Swift to be as approachable as possible to new developers, I 
>> think we can do better in this regard.
>> 
>> Rather than have a separate factory method, I propose we build the factory 
>> pattern right into Swift, by way of specialized “factory initializers”. The 
>> exact syntax was proposed by Philippe Hausler from the previous thread, and 
>> I think it is an excellent solution:
>> 
>> class AbstractBase {
>>   public factory init(type: InformationToSwitchOn) {
>>   return ConcreteImplementation(type)
>>   }
>> }
>> 
>> class ConcreteImplementation : AbstractBase {
>> 
>> }
>> 
>> Why exactly would this be useful in practice? In my own development, I’ve 
>> come across a few places where this would especially be relevant:
>> 
>> ## Class Cluster/Abstract Classes
>> This was the reasoning behind the original proposal, and I still think it 
>> would be a very valid use case. The public superclass would declare all the 
>> public methods, and could delegate off the specific implementations to the 
>> private subclasses. Alternatively, this method could be used as an easy way 
>> to handle backwards-compatibility: rather than litter the code with branches 
>> depending on the OS version, simply return the OS-appropriate subclass from 
>> the factory initializer. Very useful.
>> 
>> ## Protocol Initializers
>> Proposed by Brent Royal-Gordon, we could use factory initializers with 
>> protocol extensions to return the appropriate instance conforming to a 
>> protocol for the given needs. Similar to the class cluster/abstract class 
>> method, but can work with structs too. This would be closer to the factory 
>> method pattern, since you don’t need to know exactly what type is returned, 
>> just the protocol it conforms to.
>> 
>> ## Initializing Storyboard-backed View Controller
>> This is more specific to Apple Frameworks, but having factory initializers 
>> could definitely help here. Currently, view controllers associated with a 
>> storyboard must be initialized from the client through a factory method on 
>> the storyboard instance (storyboard. 
>> instantiateViewControllerWithIdentifier()). This works when the entire flow 
>> of the app is storyboard based, but when a single storyboard is used to 
>> configure a one-off view controller, having to initialize through the 
>> storyboard is essentially use of private implementation details; it 
>> shouldn’t matter whether the VC was designe