Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

[David Sweeris via swift-evolution]

+111eleventyone
Also, FWIW, strong +1 for everything in the generics manifesto, too.

Sent from my iPhone

> On Sep 23, 2016, at 18:50, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0142: "Permit where clauses to constrain associated types" 
> begins now and runs through September 30, 2016. The proposal is available 
> here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.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/0142-associated-types-constraints.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 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

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Sep 24, 2016, at 6:55 PM, Nate Cook  wrote:
> 
> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
> 
>> What is your evaluation of the proposal?
> [Smiling Face With Heart-Shaped Eyes Emoji]
> 
> One of the examples given (associatedtype SubSequence : Sequence where 
> SubSequence...) looks like it would run afoul of the (current?) limitations 
> on recursive protocols. Have those been resolved, or is resolving that part 
> of the work of this change?

That's a good point. Recursive protocols are a separate feature we've had on 
our wish list for Swift 4, because they can be used to clean up a bunch of 
ugliness in the standard library. Perhaps this proposal should change its 
example that doesn't depend on that not-yet-implemented feature.

  - Doug

> Other than that question, I give this the heartiest +1 I can muster!
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Definitely—this will have significant effects on not only the standard 
> library itself, but also extensions written by developers using Swift.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes!
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> n/a
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> I've read the proposal and wrestled many times with extensions that require 
> several annoyingly unnecessary `where` clauses. 
> 
> Nate
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Sep 24, 2016, at 12:58 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> This is the #1 Swift feature I have wanted for the past 2 years.
> 
> One thing I would like to see (perhaps out of scope for this proposal) is the 
> natural extension for generic parameters:
> 
> struct Box {
> var t: T
> }
> 
> extension Box where T == Int { //error: Same-type requirement makes generic 
> parameter T non-generic
> }
> 
> There is a great deal of overlap between associated types and generic 
> parameters, and it seems to me that it would be favorable to allow `==` with 
> both generic parameter operands and associatedtype operands for consistency.

Yeah, we should allow this. I think it's in the generics manifesto as well, and 
Slava Pestov has been making great progress toward unblocking the feature. I do 
think it's a separate proposal. 

  - Doug

> 
> Drew
> 
>> On September 23, 2016 at 6:51:51 PM, Douglas Gregor (dgre...@apple.com) 
>> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0142: "Permit where clauses to constrain associated types" 
>> begins now and runs through September 30, 2016. The proposal is available 
>> here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.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/0142-associated-types-constraints.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 Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> ___
> 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] Three questions about a more "dynamic" Swift for InfoQ

[Benjamin Spratling via swift-evolution]

> On Sep 26, 2016, at 3:29 PM, sergio via swift-evolution 
>  wrote:
> 
> HI all,
> 
> a debate has recently taken place within the Objective-C/Swift dev community 
> concerning the lack in Swift of something “equivalent” to Objective-C runtime 
> programming. When using Swift exclusively, there seems to be no easy 
> equivalent for Cocoa fundamental design patterns such as the Responder Chain, 
> NSUndoManager, KVC/KVO/Bindings — and in general for code that leverages 
> Objective-C's dynamic features (i.e., runtime programming). 

NSUndoManager
Generic, block-based undo would be much better in Swift than the old 
NSUndoManager.  Certainly, “invocation-based” undo is just plain gone in Swift, 
and not necessary in Obj-C.  I’m toying with a from-scratch new undo manager 
that dynamically persists a cache of large amounts of data that are filling up 
RAM.  If you’re interested, maybe I’ll post it on git hub.

Responder Chain
The easy way around Swift’s lack of a “respondsTo" is for a controller to 
provide a reference to the “next” controller in the chain.  Each controller 
class optionally conforms to a protocol, and the protocol would have the method 
the control wants to call.  I have used this extensively, and it works pretty 
well.  I’ve also discovered that a more “iOS” way of building UIs reduces the 
levels of disconnection between the Control and the Controller that was present 
in OS X, eliminating the problem in most cases.

KVO was my favorite way to do things in Obj-C; I even wrote some helper classes 
to prevent the pesky “you didn’t clean up your observers before dealloc” thing. 
 (I’m using ARC, quit bothering me with that already!)  Unfortunately, Swift’s 
init/deinit order made those classes impossible (as far as I can tell), so I 
ditched all KVO.  In the last year, developing 5 apps in pure Swift, I haven’t 
needed KVO, but I haven’t been working closely with AV modules, which used KVO 
as its preferred pattern, so I’m not sure how cumbersome the became.  For the 
one thing I did use AV- for, there was a closure-based API, and there wasn’t an 
issue.  So I’m preferring closures.  It would be nice (sigh) to use a more 
declarative approach.  I’ve recently noticed “ReativeSwift”, but haven’t had 
time to evaluate if it saves me work.

The one thing I wish I did have in the KVO genre is a callback when a weak var 
went to nil.  For example, reactively removing items from the UndoManager stack 
when the controller it references is deinit’d.  The iOS way for doing this is 
for the controller to own the undo manager 

KVC is inherently unsafe in Obj-C, and Swift is all about the safety.  Really 
all that’s happened, as best I can tell, is I have to write explicit adapters 
to create objects.  Making a protocol that implements a init?(json:JSON) 
method, and storing a reference to the protocol and calling it as needed isn’t 
that bad.  So my need for KVC has disappeared.  I get that bindings were a 
little different, but I never got that in to bindings in the first place.  It 
seemed like a whole lot of guesswork and non-safe “stringly-typed” code.  I 
much prefer knowing at the call site what my types need to be.  (CoreImage 
drives me nuts).

So I think in general, I need to see with more compelling use case than the 
ones listed for warrant the kind of dynamic features you’re talking about.  
Part of the benefit of Swift to me is the safety.  Taking the time to write my 
code in a safer way is a large part of the task of making it safe in the first 
place, but now, the compiler can catch accidental mistakes.

If anything,  I’d like to be able to dependency-inject data when a controller 
is unarchived from a .nib, for instance.

-Ben Spratling

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

Re: [swift-evolution] [Proposal draft] Conditional conformances

[Robert Widmann via swift-evolution]

+1.  I have one purely bureaucratic concern that I couldn't quite find answers 
to on a read through:

Orphan instances and more generally cross-module uniqueness of instances are 
not mentioned.  What's the policy here?  Are we locally unique with respect to 
imported modules or globally unique with respect to all importable modules?

~Robert Widmann

2016/09/26 20:18、Douglas Gregor via swift-evolution  
のメッセージ:

> Conditional conformances
> Proposal: SE-
> Author: Doug Gregor
> Review Manager: TBD
> Status: Awaiting review
> During the review process, add the following fields as needed:
> 
> Decision Notes: Rationale, Additional Commentary
> Bugs: SR-, SR-
> Previous Revision: 1
> Previous Proposal: SE-
> Introduction
> 
> Conditional conformances express the notion that a generic type will conform 
> to a particular protocol only when it's type arguments meet certain 
> requirements. For example, the Array collection can implement the Equatable 
> protocol only when its elements are themselves Equatable, which can be 
> expressed via the following conditional conformance on Equatable:
> 
> extension Array: Equatable where Element: Equatable {
>   static func ==(lhs: Array, rhs: Array) -> Bool { ... }
> }
> This feature is part of the generics manifesto because it's something that 
> fits naturally into the generics model and is expected to have a high impact 
> on the Swift standard library.
> 
> Swift-evolution thread: TBD: Discussion thread topic for that proposal
> 
> Motivation
> 
> Conditional conformances address a hole in the composability of the generics 
> system. Continuing the Array example from above, it's always been the case 
> that one could use the == operator on two arrays of Equatable type, e.g., 
> [Int]() == [Int]() would succeed. However, it doesn't compose: arrays of 
> arrays of Equatable types cannot be compared (e.g.,[Int]== [Int]will fail to 
> compile) because, even though there is an==for arrays of Equatabletype, the 
> arrays themselves are neverEquatable`.
> 
> Conditional conformances are particularly powerful when building generic 
> adapter types, which are intended to reflect the capabilities of their type 
> arguments. For example, consider the "lazy" functionality of the Swift 
> standard library's collections: using the lazy member of a sequence produces 
> a lazy adapter that conforms to the Sequence protocol, while using the lazy 
> member of a collection produces a lazy adapter that conforms to the 
> Collection protocol. In Swift 3, the only way to model this is with different 
> types. For example, the Swift standard library has four similar generic types 
> to handle a lazy collection: LazySequence, LazyCollection, 
> LazyBidirectionalCollection, and LazyRandomAccessCollection. The Swift 
> standard library uses overloading of the lazy property to decide among these:
> 
> extension Sequence {
>   var lazy: LazySequence { ... }
> }
> 
> extension Collection {
>   var lazy: LazyCollection { ... }
> }
> 
> extension BidirectionalCollection {
>   var lazy: LazyBidirectionalCollection { ... }
> }
> 
> extension RandomAccessCollection {
>   var lazy: LazyRandomAccessCollection { ... }
> }
> This approach causes an enormous amount of repetition, and doesn't scale well 
> because each more-capable type has to re-implement (or somehow forward the 
> implementation of) all of the APIs of the less-capable versions. With 
> conditional conformances, one can provide a single generic wrapper type whose 
> basic requirements meet the lowest common denominator (e.g., Sequence), but 
> which scale their capabilities with their type argument (e.g., the 
> LazySequence conforms to Collection when the type argument does, and so on).
> 
> Proposed solution
> 
> In a nutshell, the proposed solution is to allow a constrained extension of a 
> struct, enum, or class to declare protocol conformances. No additional syntax 
> is necessary for this change, because it already exists in the grammar; 
> rather, this proposal removes the limitation that results in the following 
> error:
> 
> t.swift:1:1: error: extension of type 'Array' with constraints cannot have an 
> inheritance clause
> extension Array: Equatable where Element: Equatable { }
> ^~
> Conditional conformances can only be used when the additional requirements of 
> the constrained extension are satisfied. For example, given the 
> aforementioned Array conformance to Equatable:
> 
> func f(_: T) { ... }
> 
> struct NotEquatable { }
> 
> func test(a1: [Int], a2: [NotEquatable]) {
>   f(a1)// okay: [Int] conforms to Equatable because Int conforms to 
> Equatable
>   f(a2)// error: [NotEquatable] does not conform to Equatable because 
> NotEquatable has no conformance to Equatable
> }
> Conditional conformances also have a run-time aspect, because a dynamic check 
> for a protocol conformance might rely on the evaluation of the extra 
> requirements needed to successfully use a co

[swift-evolution] [Proposal draft] Conditional conformances

[Douglas Gregor via swift-evolution]

Conditional conformances

Proposal: SE- 

Author: Doug Gregor 
Review Manager: TBD
Status: Awaiting review
During the review process, add the following fields as needed:

Decision Notes: Rationale , 
Additional Commentary 
Bugs: SR- , SR- 

Previous Revision: 1 

Previous Proposal: SE- 

 
Introduction

Conditional conformances express the notion that a generic type will conform to 
a particular protocol only when it's type arguments meet certain requirements. 
For example, the Array collection can implement the Equatable protocol only 
when its elements are themselves Equatable, which can be expressed via the 
following conditional conformance on Equatable:

extension Array: Equatable where Element: Equatable {
  static func ==(lhs: Array, rhs: Array) -> Bool { ... }
}
This feature is part of the generics manifesto 

 because it's something that fits naturally into the generics model and is 
expected to have a high impact on the Swift standard library.

Swift-evolution thread: TBD: Discussion thread topic for that proposal 

 
Motivation

Conditional conformances address a hole in the composability of the generics 
system. Continuing the Array example from above, it's always been the case that 
one could use the == operator on two arrays of Equatable type, e.g., [Int]() == 
[Int]() would succeed. However, it doesn't compose: arrays of arrays of 
Equatable types cannot be compared (e.g.,[Int] 
==
 [Int] 
will
 fail to compile) because, even though there is an==for arrays of 
Equatabletype, the arrays themselves are neverEquatable`.

Conditional conformances are particularly powerful when building generic 
adapter types, which are intended to reflect the capabilities of their type 
arguments. For example, consider the "lazy" functionality of the Swift standard 
library's collections: using the lazy member of a sequence produces a lazy 
adapter that conforms to the Sequence protocol, while using the lazy member of 
a collection produces a lazy adapter that conforms to the Collection protocol. 
In Swift 3, the only way to model this is with different types. For example, 
the Swift standard library has four similar generic types to handle a lazy 
collection: LazySequence, LazyCollection, LazyBidirectionalCollection, and 
LazyRandomAccessCollection. The Swift standard library uses overloading of the 
lazy property to decide among these:

extension Sequence {
  var lazy: LazySequence { ... }
}

extension Collection {
  var lazy: LazyCollection { ... }
}

extension BidirectionalCollection {
  var lazy: LazyBidirectionalCollection { ... }
}

extension RandomAccessCollection {
  var lazy: LazyRandomAccessCollection { ... }
}
This approach causes an enormous amount of repetition, and doesn't scale well 
because each more-capable type has to re-implement (or somehow forward the 
implementation of) all of the APIs of the less-capable versions. With 
conditional conformances, one can provide a single generic wrapper type whose 
basic requirements meet the lowest common denominator (e.g., Sequence), but 
which scale their capabilities with their type argument (e.g., the LazySequence 
conforms to Collection when the type argument does, and so on).

 
Proposed
 solution

In a nutshell, the proposed solution is to allow a constrained extension of a 
struct, enum, or class to declare protocol conformances. No additional syntax 
is necessary for this change, because it already exists in the grammar; rather, 
this proposal removes the limitation that results in the following error:

t.swift:1:1: error: extension of type 'Array' with constraints cannot have an 
inheritance clause
extension Array: Equatable where Element: Equatable { }
^~
Conditional conformances can only be used when the additional requirements of 
the constrained extension are satisfied. For example, given the aforement

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

[Robert Widmann via swift-evolution]

Being a power user of this feature, I don’t think the existing syntax is 
cumbersome enough to warrant this kind of shortcut.  I really like being able to

guard case let .dict(book) = data else {
// bail out
}
guard case let .dict(author) = book["author"] ?? .null else {
// bail out
}
guard case let .integer(age) = author["age"] ?? .null else {
// bail out
}

// now we have the age

or more succinctly

guard case let .dict(book) = data,
  case let .dict(author) = book["author"] ?? .null,
  case let .integer(age) = author["age"] ?? .null 
else {
// bail out
}
// now we have the age

Because it forces me to think about the bailout case(s) and is really not that 
much longer than your proposed syntax

guard let book = case? .dict(inputData), 
  let author = case? .dict(book?["author”]), 
  let age = case? .integer(author?["age”])
else {
// bail out
}
// now we have the age

~Robert Widmann

> On Sep 26, 2016, at 11:51 AM, Jérôme Duquennoy via swift-evolution 
>  wrote:
> 
> Summary
> The aim of this proposal is to offer a new syntax to ease some uses of enums 
> with payload.
> 
> Situation to improve:
> Enums makes it possible to have explicate typing where it was not possible 
> before. A classic example of that is filling a dictionary with data coming 
> from a file or a stream (json, plist, …) : the types of possible values is 
> finite : arrays, dicts, int, double, bool or string for json for exemple.
> An enum can represent this finite range of possible types, its make the code 
> and the API more self-documented.
> Then, you have two possibilities to deal with this enum:
> - using switch statements
> - using the if case syntax introduced by swift 2
> 
> The drawback is that those two solutions can lead to writing code with high 
> visual complexity, even though the logic behind is pretty simple.
> 
> Consider this example of a data dictionary, that a web service could have 
> returned:
> - book
>   - title: 
>   - author:
> - name: Apple
> - age: 40
> 
> We can decode this in a variable of type [String:Value], where Value is:
> 
> enum Value {
>   case integer(value: Int)
>   case string(value: String)
>   case dict(value: [String:Value])
>   case null
> }
> 
> Here is a snippet of code to access the age of the author:
> 
> if case .dict(let book) = data {
>   if case .dict(let author) = book["author"] ?? .null {
> if case .integer(let age) = author["age"] ?? .null {
>   // now we have the age
> }
>   }
> }
> 
> The multiple indentation levels can rapidly make this code unattractive to 
> read, and we need to add a null case to the enum to deal with optional values.
> 
> Proposed solution:
> I suggest to add a new syntax, using the case keyword to ease access to the 
> payload of such enums :
> 
> let payloadContent = case? .enumCase(variable)
> 
> The payloadContent variable will be an optional, that can be either nil, or 
> contain the payload of enumCase.
> If the payload contains multiple variables, payloadContent will be a tupple.
> This syntax can accommodate an optional variable as an input. If the value of 
> variable is nil, then payloadContent will be nil.
> Only enum cases with a payload can be used with this syntax (it would make no 
> sens for cases without a payload).
> 
> With that syntax, the null case of the enum can be removed, and the code to 
> access the age becomes:
> 
> let book = case? .dict(inputData)
> let author = case? .dict(book?["author"])
> let age = case? .integer(author?["age"])
> 
> Advantages:
> - It leverages the well established notion of optional, and similar logic 
> already exists in the language (for the as? operator notably).
> - It does not add a new keyword
> - It promotes the use of enum to enforce explicit typing, which leads to more 
> self-documenting code
> - It reduces the complexity of the code in situations such as the one of the 
> exemple
> 
> Drawbacks:
> - It adds a third use of the case keyword. 
> - In the proposed syntax, the variable between parenthesis is not the 
> payload, but the variable to decode. This might be disturbing, as it differs 
> from the other syntax of enum values.
> - If the payload is an optional, it is not possible to differentiate a 
> non-matching case and a matching case a nil payload.
> 
> Alternatives:
> - Another syntax without parenthesis could be used to avoid the second 
> drawback:
> let payload = case? .enumCase variable
> 
> Impact on existing code:
> None, this is adding a new syntax
> 
> 
> This proposal would have no impact on the ABI, so it probably does not fit 
> the stage 1 of swift 4’s roadmap. But I would be glad to have your feedback, 
> so that I can have a proposal ready once we enter stage 2.
> So what your thoughts on that proposal ?
> 
> Thanks
> 
> Jerome
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolut

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

[Johannes Neubauer via swift-evolution]

Von meinem iPhone gesendet

> Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution 
> :
> 
> 
> 
> ~Robert Widmann
> 
> 2016/09/26 16:29、sergio via swift-evolution  
> のメッセージ:
> 
>> HI all,
>> 
>> a debate has recently taken place within the Objective-C/Swift dev community 
>> concerning the lack in Swift of something “equivalent” to Objective-C 
>> runtime programming. When using Swift exclusively, there seems to be no easy 
>> equivalent for Cocoa fundamental design patterns such as the Responder 
>> Chain, NSUndoManager, KVC/KVO/Bindings — and in general for code that 
>> leverages Objective-C's dynamic features (i.e., runtime programming). 
>> 
>> According to some developers, dynamic features in Ocjective-C grant easy 
>> coding and high decoupling and there are concerns that Swift might make 
>> harder a number of common Objective-C tasks (e.g., by increasing boilerplate 
>> code, lowering readability, making high use of switch, etc.) and eventually 
>> increase development time.
>> 
>> In this context, is interesting to know how those concerns are viewed within 
>> the Swift dev community and how they could be tackled. Thus, I would like to 
>> ask three questions that will be the base for an InfoQ article on the topic:
>> 
>> 
>> 1. Do you envision a more dynamic Swift? Should some level of dynamism 
>> be added at the language or framework level (e.g., to make dynamic dispatch 
>> or some form of message passing possible, while ruling out trickier features 
>> such as method swizzling and others) possible ? Should Swift be dynamic at 
>> all?
> 
> No, and I think moving towards a more dynamic Swift now without 
> as-of-yet-seen significant justification would be a mistake.  Swift should be 
> as static as possible.  We should be making every attempt to pare down the 
> existing runtime and quietly transition those that rely on dynamism to 
> checked reflection (yes, that is not in fact an oxymoron).  The more the 
> compiler knows about your program, the better it does.  Period.

I do not agree (fully). Although static type checking is great, object 
orientation is too. Dynamic dispatch and therefore (subtype) polymorphism is a 
wonderful thing. Going down the road to make every call static is an extreme 
that won't help anybody. As always the right balance makes the deal.

All the best
Johannes

> 
>> 
>> 2. What is the challenge of making a more dynamic Swift (or adding 
>> features to it to help solve the same kind of issues that are solved in ObjC 
>> through dynamism)? How could that be achieved without making Swift a less 
>> safe language? [e.g., reflection, macros, etc.]
> 
> There are very few dynamic patterns that aren't subsumed by the current 
> model.  That said, two big ones I know of are Realm's approach of using 
> "runtime-metaprogramming" to derive models and combining static typing with 
> Clojure-style coercible data structures that share a common core.   The first 
> can be subsumed by better reflection primitives, the second is more 
> difficult.  Static Swift means room for potential optimizations that could 
> destroy the integrity of any system that thinks it knows enough to coerce 
> terms around itself (this kind of programming is powerful precisely because 
> of this knowledge).  Perhaps that's not a bad thing.  If you know your types 
> ahead of time - which you do if you're trying to perform coercions - you 
> should be able to write down something to convince the type checker.  If you 
> can't, it's an expressiveness problem we should deal with at the level of the 
> type system.
> 
>> 
>> Thanks a lot in advance!
>> Sergio
>> 
>> —
>> 
>> Sergio De Simone
>> https://www.infoq.com/author/Sergio-De-Simone
>> ___
>> 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] Should Swift apply "statement scope" for ARC

[Joe Groff via swift-evolution]

> On Sep 25, 2016, at 3:19 AM, John Holdsworth  wrote:
> 
> 
>> On 25 Sep 2016, at 04:07, Michael Gottesman > > wrote:
>> 
>>> init(imageProducer:ImageProducer) {
>>> withExtendedLifetime(CanvasBase()) {
>>> super.init(javaObject: $0.javaObject)
>>> }
>>> image = createImage(imageProducer)
>>> }
>>> 
>>> ..but the compiler was having none of it.
>> 
>> What was the error? I am assuming that super.init was not in the same 
>> function?
> 
> Sorry, I should have included that in the email. The error was:
> 
> error: initializer chaining ('super.init') cannot be nested in another 
> expression
> 
> Is it possible to build in an exception for withExtendedLifetime?

The block structure of `withExtendedLifetime` is a bit of a lie. It looks a bit 
goofy, but it's just as good to have an empty `withExtendedLifetime` call after 
the super.init:

init(imageProducer: ImageProducer) {
  let canvasBase = CanvasBase()
  super.init(javaObject: CanvasBase())
  withExtendedLifetime(canvasBase) {}
  image = createImage(imageProducer)
}

If you look at the standard library implementation of `withExtendedLifetime`, 
you'll see that all it does is `defer` a call to the underlying internal 
`_fixLifetime` operation:

https://github.com/apple/swift/blob/master/stdlib/public/core/LifetimeManager.swift#L15
 


It may be a better design to just expose `fixLifetime` directly instead of 
trying to tie it to a scope.

-Joe

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

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

[Robert Widmann via swift-evolution]

~Robert Widmann

2016/09/26 16:29、sergio via swift-evolution  のメッセージ:

> HI all,
> 
> a debate has recently taken place within the Objective-C/Swift dev community 
> concerning the lack in Swift of something “equivalent” to Objective-C runtime 
> programming. When using Swift exclusively, there seems to be no easy 
> equivalent for Cocoa fundamental design patterns such as the Responder Chain, 
> NSUndoManager, KVC/KVO/Bindings ― and in general for code that leverages 
> Objective-C's dynamic features (i.e., runtime programming). 
> 
> According to some developers, dynamic features in Ocjective-C grant easy 
> coding and high decoupling and there are concerns that Swift might make 
> harder a number of common Objective-C tasks (e.g., by increasing boilerplate 
> code, lowering readability, making high use of switch, etc.) and eventually 
> increase development time.
> 
> In this context, is interesting to know how those concerns are viewed within 
> the Swift dev community and how they could be tackled. Thus, I would like to 
> ask three questions that will be the base for an InfoQ article on the topic:
> 
> 
> 1. Do you envision a more dynamic Swift? Should some level of dynamism be 
> added at the language or framework level (e.g., to make dynamic dispatch or 
> some form of message passing possible, while ruling out trickier features 
> such as method swizzling and others) possible ? Should Swift be dynamic at 
> all?

No, and I think moving towards a more dynamic Swift now without as-of-yet-seen 
significant justification would be a mistake.  Swift should be as static as 
possible.  We should be making every attempt to pare down the existing runtime 
and quietly transition those that rely on dynamism to checked reflection (yes, 
that is not in fact an oxymoron).  The more the compiler knows about your 
program, the better it does.  Period.

> 
> 2. What is the challenge of making a more dynamic Swift (or adding 
> features to it to help solve the same kind of issues that are solved in ObjC 
> through dynamism)? How could that be achieved without making Swift a less 
> safe language? [e.g., reflection, macros, etc.]

There are very few dynamic patterns that aren't subsumed by the current model.  
That said, two big ones I know of are Realm's approach of using 
"runtime-metaprogramming" to derive models and combining static typing with 
Clojure-style coercible data structures that share a common core.   The first 
can be subsumed by better reflection primitives, the second is more difficult.  
Static Swift means room for potential optimizations that could destroy the 
integrity of any system that thinks it knows enough to coerce terms around 
itself (this kind of programming is powerful precisely because of this 
knowledge).  Perhaps that's not a bad thing.  If you know your types ahead of 
time - which you do if you're trying to perform coercions - you should be able 
to write down something to convince the type checker.  If you can't, it's an 
expressiveness problem we should deal with at the level of the type system.

> 
> Thanks a lot in advance!
> Sergio
> 
> ―
> 
> Sergio De Simone
> https://www.infoq.com/author/Sergio-De-Simone
> ___
> 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] class/struct inner member access scope classifier

[Nevin Brackett-Rozinsky via swift-evolution]

Just to weigh in here, I too am enjoying Swift 3 greatly.

However, my experience with access modifiers is rather different. I am very
glad that `internal` is the default: this reduces extraneous noise for the
common case, and makes it really easy for new programmers to jump in.

Furthermore, I am beginning to think that changing the meaning of `private`
and introducing `fileprivate` may not have been worth the complexity. Even
with file-scope visibility, one must still use the full path to a member in
order to use it: eg. MyClass.InnerStruct.specialFunction(), so the risk of
collisions is minuscule.

Before the change, the only visibility scopes to consider were file,
module, and everywhere. Now there can be nested private scopes, which may
be “unutterable” in the sense that there is no way to declare a member in
one scope with the same visibility as a private member of an outer scope.

When using the pattern whereby a type is built with many extensions in a
single file, shared helper members must now be declared `fileprivate`
whereas before they were simply `private`. I readily acknowledge that this
is a *small* annoyance, but it is nevertheless that much extra typing and
and that much extra noise.

I don’t expect that reverting such a major change would be worth the
upheaval, especially since many people seem to like it, but I think there
is value in the simpler model that we used to have.

In any event, I *do* think it would be worth renaming “fileprivate” to
something shorter, if a suitable word can be found. I remember how much
bikeshedding went on the first time around, including several people trying
to find a better term than “fileprivate” without any luck, so it may well
turn out that there just isn’t a suitable replacement.

If there is one though, count me on the side in favor of shortening
“fileprivate”.

Nevin



On Mon, Sep 26, 2016 at 3:58 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello! Hope you are all OK!
>
> Using and converting To Swift 3.0 with many advantages
> and very little problems.OK, thanks to all !
> also for the reasonably smart converter. Yes, yes, yes, I’m
> still missing the classical for ;; loop (don’t wake me up
> again plse :o)  but overall it is quite good!
>
> I also value the -finally correct- meaning of the scope
> qualifier “private” , thanks,
> which is as it should be (imho) inner scope restricting.
>
> As for “fileprivate”: as yet, I haven’t found a case
> where I should use “fileprivate” also because to me, the contents of
> a file should in principle not have anything to do with the entities
> contained in it, as a file should be just an data carrier. Therefore,
> it should have no effect to wether or not concatenate source.swift files
> into one big file for example, although I would not recommend this.
>
> As far as I can see without binoculars, the “fileprivate” acces modifier
> could be dropped, were it not for source compatibility reasons...
>
> Unless I am missing something:
> Still. something is not quite right yet, I think.
> Just like in a Swift function, I don’t want the inner elements
> of a class (or struct ?) to be visible in outer scope!
> This is the default case in most OOP languages.
> I fail to understand why this is not so in Swift, please enlighten me.
>
> As it is now, and as far as I know, I have to explicitly
> declare *all* entities inside a class that should not be accessible
> outside the class as private, like in this real-world example:
>
>
> class TG3DGauge: SCNNode
> {
>
>
> private var needles = [SCNNode]()
> private var fmtStr = “" // private should be the default imho.
>
>
> var value: CGFloat = 0
> {
> didSet  // trigger value change, rotate needles etc.
> {
> valueChange()
> }
> }
>
>
> private var nodeUnitText = SCNNode()
> private var nodeValueText = SCNNode()
>
>
> private var valRange: ClosedRange = (0...100.0)
>
>
> var rangeNeedlesActive: Bool = true
> {
> didSet
> {
> needles[2].isHidden = !rangeNeedlesActive
> needles[3].isHidden = !rangeNeedlesActive
> }
> }
>
>
> private var valScaleFactor: CGFloat = 1
>
> // etc. more stuff
> .
> .
> } // end class TG3DGauge
>
>
> It should (imho) be the other way around: that every member of
> a class is private by default - that is invisible outside the scope
> were it is declared in. This was (and still is) the case with Objective C,
> where you need to explicitly declaring them in  the  sourcefile.h file
> to make them visible and accessible in the outer scope
> Everything else, as existing in the sourcefile.m remains hidden, not
> visible
> in the outer scope.
>
> As a solution/suggestion and also to prevent the gruesome
> horror (did i already wrote something about that?  :o) of source breaking.
> I could think of the “closedscope” (or some other word)
> access modifier, which states that all thing

[swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

[sergio via swift-evolution]

HI all,

a debate has recently taken place within the Objective-C/Swift dev community 
concerning the lack in Swift of something “equivalent” to Objective-C runtime 
programming. When using Swift exclusively, there seems to be no easy equivalent 
for Cocoa fundamental design patterns such as the Responder Chain, 
NSUndoManager, KVC/KVO/Bindings — and in general for code that leverages 
Objective-C's dynamic features (i.e., runtime programming). 

According to some developers, dynamic features in Ocjective-C grant easy coding 
and high decoupling and there are concerns that Swift might make harder a 
number of common Objective-C tasks (e.g., by increasing boilerplate code, 
lowering readability, making high use of switch, etc.) and eventually increase 
development time.

In this context, is interesting to know how those concerns are viewed within 
the Swift dev community and how they could be tackled. Thus, I would like to 
ask three questions that will be the base for an InfoQ article on the topic:


1. Do you envision a more dynamic Swift? Should some level of dynamism be 
added at the language or framework level (e.g., to make dynamic dispatch or 
some form of message passing possible, while ruling out trickier features such 
as method swizzling and others) possible ? Should Swift be dynamic at all?

2. What is the challenge of making a more dynamic Swift (or adding features 
to it to help solve the same kind of issues that are solved in ObjC through 
dynamism)? How could that be achieved without making Swift a less safe 
language? [e.g., reflection, macros, etc.]

3. Are you aware of any work that has been/is being done in Swift 
development (Swift 3/Swift 4) to make Swift more capable of addressing the 
above mentioned concerns?


Thanks a lot in advance!
Sergio

—

Sergio De Simone
https://www.infoq.com/author/Sergio-De-Simone___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Karl via swift-evolution]

> On 14 Sep 2016, at 18:08, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>> On Sep 10, 2016, at 5:53 PM, Andrew Trick  wrote:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
>> 
>> The review period has been extended until September 14. The 
>> UnsafeRawBufferPointer type name is settled, but we still need to come up 
>> with an answer for the name of the new closure taking functions:
>> 
>> withXyz() should normally reveal the closure argument type as Xyz. That's 
>> why I originally proposed UnsafeBytes as the type name. Now that we've 
>> decided to use the descriptive type instead we have a problem…
> 
> I was totally wrong about this policy. In closure-taking “withXyz" functions, 
> “Xyz" should reveal the role of the closure argument, not its type. We do not 
> need to repeat type information.
> 
> We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as 
> it stands.
> 
> Note that `withRawBytes` was a strong contender, but at this time it's more 
> important to consistently follow the convention for using `Unsafe` in the 
> closure name whenever the closure argument is unsafe (e.g. you can't return 
> it from the closure). We may want to revisit this logic later (in some sense 
> Unsafe is redundant), but when we do that, we also need to reevaluate all of 
> our withUnsafe APIs. Furthermore, we would want to change Foundation Data's 
> API to be consistent. These are bigger debates that can be deferred.

Annotating that a parameter of a closure should not escape the closure is 
probably a worthwhile thing to have, anyway. Currently we only allow that for 
function-type parameters, but there are other parameters you might give (such 
as the pointer in `String.withCString()`’s closure) which should not escape 
their context.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] class/struct inner member access scope classifier

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

Hello! Hope you are all OK! 

Using and converting To Swift 3.0 with many advantages
and very little problems.OK, thanks to all !
also for the reasonably smart converter. Yes, yes, yes, I’m
still missing the classical for ;; loop (don’t wake me up 
again plse :o)  but overall it is quite good!

I also value the -finally correct- meaning of the scope qualifier “private” , 
thanks, 
which is as it should be (imho) inner scope restricting. 

As for “fileprivate”: as yet, I haven’t found a case
where I should use “fileprivate” also because to me, the contents of
a file should in principle not have anything to do with the entities
contained in it, as a file should be just an data carrier. Therefore, 
it should have no effect to wether or not concatenate source.swift files
into one big file for example, although I would not recommend this.

As far as I can see without binoculars, the “fileprivate” acces modifier
could be dropped, were it not for source compatibility reasons... 
  
Unless I am missing something: 
Still. something is not quite right yet, I think.
Just like in a Swift function, I don’t want the inner elements
of a class (or struct ?) to be visible in outer scope!
This is the default case in most OOP languages. 
I fail to understand why this is not so in Swift, please enlighten me. 

As it is now, and as far as I know, I have to explicitly
declare *all* entities inside a class that should not be accessible
outside the class as private, like in this real-world example:  


class TG3DGauge: SCNNode
{

private var needles = [SCNNode]()
private var fmtStr = “" // private should be the default imho.

var value: CGFloat = 0
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

private var nodeUnitText = SCNNode()
private var nodeValueText = SCNNode()

private var valRange: ClosedRange = (0...100.0)

var rangeNeedlesActive: Bool = true
{
didSet
{
needles[2].isHidden = !rangeNeedlesActive
needles[3].isHidden = !rangeNeedlesActive
}
}

private var valScaleFactor: CGFloat = 1

// etc. more stuff
.
.
} // end class TG3DGauge


It should (imho) be the other way around: that every member of 
a class is private by default - that is invisible outside the scope 
were it is declared in. This was (and still is) the case with Objective C,
where you need to explicitly declaring them in  the  sourcefile.h file
to make them visible and accessible in the outer scope 
Everything else, as existing in the sourcefile.m remains hidden, not visible
in the outer scope.

As a solution/suggestion and also to prevent the gruesome
horror (did i already wrote something about that?  :o) of source breaking.
I could think of the “closedscope” (or some other word) 
access modifier, which states that all things declared inside a class, 
are private within the class and thus invisible in the outer scope, unless
preceeded with an overriding acces scope modifier like “public", “internal" or 
"fileprivate” 



closedscope class TG3DGauge: SCNNode
{

var needles = [SCNNode]()  // is now private by default
var fmtStr = “"// is now private by default

public var value: CGFloat = 0 // Public!! visible outside class also for 
“fileprivate" or “internal”  
{
didSet  // trigger value change, rotate needles etc.
{
valueChange()
}
}

var nodeUnitText = SCNNode()  // is now private by default
var nodeValueText = SCNNode() // is now private by default

//etc.

This “closedscope" modifier should only be effective for the current class, not 
its superclass(es),
allowing one to hide/reveal entities in each class independently being part of 
the hierarchy.
Also entities declared private should not be visible in descendant classes

Also please note that I do miss the “protected” scope access modifier which 
allows entities to be exclusively
visible to descendant classes, as in Java. Why not implement it in Swift as 
well?  

AFAICS:  All mentioned here would not be a source breaking. 

Opinions, remarks welcome.

met vriendelijke groeten
Ted








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

Re: [swift-evolution] Source-breaking proposals?

[Dave Abrahams via swift-evolution]

on Sun Sep 25 2016, Karl  wrote:

>> On 25 Sep 2016, at 18:38, Anton Zhilin via swift-evolution 
>>  wrote:
>> 
>> Do I miss something, or proposals with source-breaking changes still can't 
>> be submitted?
>> When will corresponsing guidelines be out? Are there any plans on that 
>> matter?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I believe the situation is that we’re going to support Swift 3 syntax with a 
> compiler flag, which frees us to make source-breaking changes for Swift 4. 
>
> AFAIK, how we support this in the compiler isn’t determined yet.
>
> That’s what I take from Ted’s email: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025587.html

That's correct.

-- 
-Dave

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

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

[Ben Rimmington via swift-evolution]

Re: 


Is the "Versioned API" design in docs/LibraryEvolution.rst not intended for the 
Swift standard library?





-- Ben

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington via swift-evolution]

> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution 
>  wrote:
> 
>> On Sep 10, 2016, at 5:53 PM, Andrew Trick  wrote:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
>> 
>> The review period has been extended until September 14. The 
>> UnsafeRawBufferPointer type name is settled, but we still need to come up 
>> with an answer for the name of the new closure taking functions:
>> 
>> withXyz() should normally reveal the closure argument type as Xyz. That's 
>> why I originally proposed UnsafeBytes as the type name. Now that we've 
>> decided to use the descriptive type instead we have a problem…
> 
> I was totally wrong about this policy. In closure-taking “withXyz" functions, 
> “Xyz" should reveal the role of the closure argument, not its type. We do not 
> need to repeat type information.
> 
> We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as 
> it stands.
> 
> Note that `withRawBytes` was a strong contender, but at this time it's more 
> important to consistently follow the convention for using `Unsafe` in the 
> closure name whenever the closure argument is unsafe (e.g. you can't return 
> it from the closure). We may want to revisit this logic later (in some sense 
> Unsafe is redundant), but when we do that, we also need to reevaluate all of 
> our withUnsafe APIs. Furthermore, we would want to change Foundation Data's 
> API to be consistent. These are bigger debates that can be deferred.

An example without `Unsafe` in the function name:



-- Ben

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

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

[Rien via swift-evolution]

While I don’t have time to get into detail right now, you may be interested in 
an approach I used for a JSON framework: http://github.com/swiftrien/swifterjson
In that approach I used the unix pipe operator “|” to chain a series of JSON 
accesses. In your example that would be written as:

guard let age = (json|”book”|”author”|”age”)?.integerValue else {…}

Maybe this could be of significance to your proposal?

Regards,
Rien.

> On 26 Sep 2016, at 17:51, Jérôme Duquennoy via swift-evolution 
>  wrote:
> 
> Summary
> The aim of this proposal is to offer a new syntax to ease some uses of enums 
> with payload.
> 
> Situation to improve:
> Enums makes it possible to have explicate typing where it was not possible 
> before. A classic example of that is filling a dictionary with data coming 
> from a file or a stream (json, plist, …) : the types of possible values is 
> finite : arrays, dicts, int, double, bool or string for json for exemple.
> An enum can represent this finite range of possible types, its make the code 
> and the API more self-documented.
> Then, you have two possibilities to deal with this enum:
> - using switch statements
> - using the if case syntax introduced by swift 2
> 
> The drawback is that those two solutions can lead to writing code with high 
> visual complexity, even though the logic behind is pretty simple.
> 
> Consider this example of a data dictionary, that a web service could have 
> returned:
> - book
>   - title: 
>   - author:
> - name: Apple
> - age: 40
> 
> We can decode this in a variable of type [String:Value], where Value is:
> 
> enum Value {
>   case integer(value: Int)
>   case string(value: String)
>   case dict(value: [String:Value])
>   case null
> }
> 
> Here is a snippet of code to access the age of the author:
> 
> if case .dict(let book) = data {
>   if case .dict(let author) = book["author"] ?? .null {
> if case .integer(let age) = author["age"] ?? .null {
>   // now we have the age
> }
>   }
> }
> 
> The multiple indentation levels can rapidly make this code unattractive to 
> read, and we need to add a null case to the enum to deal with optional values.
> 
> Proposed solution:
> I suggest to add a new syntax, using the case keyword to ease access to the 
> payload of such enums :
> 
> let payloadContent = case? .enumCase(variable)
> 
> The payloadContent variable will be an optional, that can be either nil, or 
> contain the payload of enumCase.
> If the payload contains multiple variables, payloadContent will be a tupple.
> This syntax can accommodate an optional variable as an input. If the value of 
> variable is nil, then payloadContent will be nil.
> Only enum cases with a payload can be used with this syntax (it would make no 
> sens for cases without a payload).
> 
> With that syntax, the null case of the enum can be removed, and the code to 
> access the age becomes:
> 
> let book = case? .dict(inputData)
> let author = case? .dict(book?["author"])
> let age = case? .integer(author?["age"])
> 
> Advantages:
> - It leverages the well established notion of optional, and similar logic 
> already exists in the language (for the as? operator notably).
> - It does not add a new keyword
> - It promotes the use of enum to enforce explicit typing, which leads to more 
> self-documenting code
> - It reduces the complexity of the code in situations such as the one of the 
> exemple
> 
> Drawbacks:
> - It adds a third use of the case keyword. 
> - In the proposed syntax, the variable between parenthesis is not the 
> payload, but the variable to decode. This might be disturbing, as it differs 
> from the other syntax of enum values.
> - If the payload is an optional, it is not possible to differentiate a 
> non-matching case and a matching case a nil payload.
> 
> Alternatives:
> - Another syntax without parenthesis could be used to avoid the second 
> drawback:
> let payload = case? .enumCase variable
> 
> Impact on existing code:
> None, this is adding a new syntax
> 
> 
> This proposal would have no impact on the ABI, so it probably does not fit 
> the stage 1 of swift 4’s roadmap. But I would be glad to have your feedback, 
> so that I can have a proposal ready once we enter stage 2.
> So what your thoughts on that proposal ?
> 
> Thanks
> 
> Jerome
> 
> ___
> 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] [proposal draft] new syntax to access a given case's payload

[Jérôme Duquennoy via swift-evolution]

Summary
The aim of this proposal is to offer a new syntax to ease some uses of enums 
with payload.

Situation to improve:
Enums makes it possible to have explicate typing where it was not possible 
before. A classic example of that is filling a dictionary with data coming from 
a file or a stream (json, plist, …) : the types of possible values is finite : 
arrays, dicts, int, double, bool or string for json for exemple.
An enum can represent this finite range of possible types, its make the code 
and the API more self-documented.
Then, you have two possibilities to deal with this enum:
- using switch statements
- using the if case syntax introduced by swift 2

The drawback is that those two solutions can lead to writing code with high 
visual complexity, even though the logic behind is pretty simple.

Consider this example of a data dictionary, that a web service could have 
returned:
- book
  - title: 
  - author:
- name: Apple
- age: 40

We can decode this in a variable of type [String:Value], where Value is:

enum Value {
  case integer(value: Int)
  case string(value: String)
  case dict(value: [String:Value])
  case null
}

Here is a snippet of code to access the age of the author:

if case .dict(let book) = data {
  if case .dict(let author) = book["author"] ?? .null {
if case .integer(let age) = author["age"] ?? .null {
  // now we have the age
}
  }
}

The multiple indentation levels can rapidly make this code unattractive to 
read, and we need to add a null case to the enum to deal with optional values.

Proposed solution:
I suggest to add a new syntax, using the case keyword to ease access to the 
payload of such enums :

let payloadContent = case? .enumCase(variable)

The payloadContent variable will be an optional, that can be either nil, or 
contain the payload of enumCase.
If the payload contains multiple variables, payloadContent will be a tupple.
This syntax can accommodate an optional variable as an input. If the value of 
variable is nil, then payloadContent will be nil.
Only enum cases with a payload can be used with this syntax (it would make no 
sens for cases without a payload).

With that syntax, the null case of the enum can be removed, and the code to 
access the age becomes:

let book = case? .dict(inputData)
let author = case? .dict(book?["author"])
let age = case? .integer(author?["age"])

Advantages:
- It leverages the well established notion of optional, and similar logic 
already exists in the language (for the as? operator notably).
- It does not add a new keyword
- It promotes the use of enum to enforce explicit typing, which leads to more 
self-documenting code
- It reduces the complexity of the code in situations such as the one of the 
exemple

Drawbacks:
- It adds a third use of the case keyword. 
- In the proposed syntax, the variable between parenthesis is not the payload, 
but the variable to decode. This might be disturbing, as it differs from the 
other syntax of enum values.
- If the payload is an optional, it is not possible to differentiate a 
non-matching case and a matching case a nil payload.

Alternatives:
- Another syntax without parenthesis could be used to avoid the second drawback:
let payload = case? .enumCase variable

Impact on existing code:
None, this is adding a new syntax


This proposal would have no impact on the ABI, so it probably does not fit the 
stage 1 of swift 4’s roadmap. But I would be glad to have your feedback, so 
that I can have a proposal ready once we enter stage 2.
So what your thoughts on that proposal ?

Thanks

Jerome

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Howard Lovatt via swift-evolution]

> The review of SE-0142: "Permit where clauses to constrain associated types" 
> begins now and runs through September 30, 2016. The proposal is available 
> here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md

> What is your evaluation of the proposal?
It is a valuable addition to Swift and certainly something I have desired. 
However I feel the proposed syntax is long winded, something associated types 
already suffer from. There also seems to be an inconsistency in specifying 
constraints sometimes in where clauses and other times as a constraint on the 
associated type. 

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

> Does this proposal fit well with the feel and direction of Swift?
Not quite. See above. 

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
It is similar to generics and begs the question why not abandon associated 
types and just have generics on protocols. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Mainly my comments are based on writing my own collection library in Swift and 
comparing that exercise to similar in Java and C++. It is at the moment 
significantly harder than in Java but easier than C++. Any improvement in 
associated types would be welcome. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Propagating Optionals

[Jeremy Pereira via swift-evolution]

> On 26 Sep 2016, at 00:26, William Sumner via swift-evolution 
>  wrote:
> 
>> 
>>  let roomCount = john.residence.numberOfRooms
>> 
>>  // error: value of optional type 'Residence?' not unwrapped; did
>> you mean to use '!' or '?'?
>> 
>> As general rule of thumb, whenever I get an error and the system tells
>> me what I probably meant, that is a pretty good sign the system isn't
>> doing all it can for me and making me jump through an unnecessary
>> hoop.

In this case, the compiler hasn’t told you what you probably mean. It’s given 
you two different meanings to choose from and hasn’t actually excluded other 
ways to fix the issue e.g. if let or guard let or even an extension to Optional.

As Haravikk and Brent have said, assuming either of these as the default is 
dangerous.

Assuming ! as the default, to my mind negates the point of introducing 
optionals at all, we might as well go back to null references. The whole point 
is to eliminate the “no value” problem at compile time, not run time.

Assuming ? as the default is more insidious. The application may carry on and 
may persist state that is incorrect.

I think the current behaviour is correct.

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

Re: [swift-evolution] Equatable auto-write func == Proposal

[Martin Waitz via swift-evolution]

Hi,

Am 2016-09-26 12:53, schrieb Francisco Costa via swift-evolution:

+1 for making enums with payloads Equatable by default. Right now this
requires lots of copy-paste boiler plate that can easily result in
bugs.


Of course, making structs and enums Equatable should be much easier (the 
same is true for e.g. Hashable).
However, I still think Protocol conformance should be something which is 
specified explicitly.


When we improve support for generics we might be able to provide a 
default implementation for those cases where all fields are already 
Equatable/Hashable.

Then, making your struct conform to Equatable would be easy:

extension MyStruct: Equatable {}

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

Re: [swift-evolution] Equatable auto-write func == Proposal

[Francisco Costa via swift-evolution]

+1 for making enums with payloads Equatable by default. Right now this
requires lots of copy-paste boiler plate that can easily result in bugs.

As for the general struct case, I think there could be a default
implementation but we should be able to overwrite `==` if we need to.
Doesn't seem sensible to me comparing several inner objects and arrays if a
single `uuid` would suffice.

Francisco


On Mon, Sep 19, 2016 at 3:15 PM, Jérôme Duquennoy via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi guys,
>
> It would be awesome if with this evolution, we could also auto-write
> equality operators for enum with equatable payloads.
>
> Today, considering this enum
>
> enum SimpleEnum {
>   case case1
>   case case2
> }
>
> the condition SimpleEnum.case1 == SimpleEnum.case1 compiles and return
> true.
>
> But if the enum has a payload
>
> enum EnumWithPayload {
>   case integer(value: Int)
>   case float(value: Float)
> }
>
> the condition EnumWithPayload.integer(value: 1) == 
> EnumWithPayload.integer(value:
> 1) does not compile: operator == does not exist for that type.
>
> Hand-writing this missing equality operator turns out to be pretty
> fastidious and error prone, notably because you might prefer to not use a
> “default” case, to take advantage of the completeness check of the compiler.
> So you have to write n * (n-1) cases and that can be a lot of cases !
>
> Jerome
>
> > Good point.
> >
> > The real push here is that when the programmer *does* declare a type
> Equatable and the op == has an obvious implementation, that the programmer
> shouldn’t have to manually implement it him/herself. This would apply only
> to types that have been declared Equatable and that consist of exclusively
> properties which have all also been declared Equatable.
> >
> > This would work much like the Haskell Eq class.
> >
> > > On Sep 12, 2016, at 12:03 PM, Robert Widmann gmail.com>wrote:
> > >
> > > Please be careful when wording this proposal. You want derived
> conformances, but don't obscure that message with the claim that every type
> admits a useful Equatable instance. It is most certainly not the case that
> every value type has a useful (read [mostly]: decidable) equality. A few
> counterexamples, the type of lazy streams (https://github.com/typelift/
> Swiftz/blob/swift-develop/Swiftz/Stream.swift#L24 //github.com/typelift/Swiftz/blob/swift-develop/Swiftz/Stream.swift#L24>)
> requires infinite space to evaluate a useful answer. The type of functions
> [without a modulus of continuity] also don't admit a useful, or even
> canonical, equality (in Swift at least).
> > >
> > > ~Robert Widmann
> > >
> > > 2016/09/10 8:24、Daniel Tartaglia via swift-evolution at swift.org>のメッセージ:
> > >
> > > > Now that Swift 3 is out the door, I’m going to float this proposal
> again…
> > > >
> > > > Given that every value type should be equatable (rational here):
> https://www.andrewcbancroft.com/2015/07/01/every-swift-
> value-type-should-be-equatable/ 01/every-swift-value-type-should-be-equatable/>
> > > > And that many, if not most, value types consist of properties that
> are value types.
> > > > Then the language should make it easy to conform to the Equatable
> protocol.
> > > >
> > > > In other words, if I declare my value type as Equatable, and it is
> exclusively composed of value types that are already equatable, then
> implementing the actual == function should be optional (or maybe even
> forbidden.)
> > > >
> > > > Implementing == in such cases is tedious boilerplate that the
> compiler should be able to infer on its own.
> > > >
> > > > Does anybody want to help me write up an official proposal?
> >
> >
> >
>
> ___
> 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] Propagating Optionals

[Haravikk via swift-evolution]

> On 25 Sep 2016, at 21:19, Trans via swift-evolution 
>  wrote:
> 
> "john.residence.numberOfRooms" could just behave one way or the other

While I understand where you're coming from, I think the problem is that 
whichever version we specified as a guess would be wrong some of the time 
anyway, which is why it's better to just force the developer to think about it 
and put the correct symbol(s) for their use case.

For example, if we assumed a behaviour of !, then the user is going to get 
runtime errors that might not always occur (say the residence is nil 5% of the 
time, that's potentially only a 5% chance of triggering the error during 
testing). If we assume ? as the correct behaviour then the developer could end 
up with an error much further down their code depending upon when and how they 
use the result of the statement, and looking back at the code it won't be as 
obvious where that optional came from (especially if you meant to put an 
exclamation mark but didn't, so are assuming a non-optional value).

It's just one of those cases where I think it's better to force the developer 
to be explicit, rather than try to guess what they meant to do.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

[Goffredo Marocchi via swift-evolution]

Sorry this should have gone to the list...

Sent from my iPhone

> On 24 Sep 2016, at 09:19, Goffredo Marocchi  wrote:
> 
> Strong 1+, Swift would benefit from being abbot less dogmatic at compile time 
> and allow for more runtime flexibility especially with regards to third party 
> libraries.
> 
> The compiler construct is needed, but there are times where you want the 
> flexibility to be there when the code runs on a particular device with a 
> particular OS.
> 
> Sent from my iPhone
> 
>> On 24 Sep 2016, at 00:38, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0141 "Availability by Swift version" begins now and runs 
>> through September 28, 2016. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.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/0141-available-by-swift-version.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 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

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
Seems like it will be greatly appreciated in the future for library authors.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, it will gives us a little bit more flexibility to break source/binary 
compatibility.

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

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

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Two reads.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution