[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

[Joe Groff via swift-evolution]

I’d like to investigate separating Objective-C bridging from the behavior of 
the as/as?/is operator family again for Swift 4. Last year, I proposed SE–0083 
,
 but we deferred the proposal for lack of time to evaluate its impact. As 
complicating factors, we now have source compatibility with Swift 3 as a 
requirement, and the id-as-Any work from SE–0116 

 more or less requires bridging dynamic casts to work. I think we can 
nonetheless make important improvements in this area in order to simplify the 
core language and provide more portable behavior across platforms with and 
without ObjC interop. In retrospect, submitting SE–0083 as an omnibus “fix 
casting” proposal was a mistake. We can separate out a few smaller subproblems 
from the overall concept:

Replacing as for bridging coercion

Swift 0 shipped with implicit conversions between standard library value types 
and their bridged Cocoa classes in both directions, and as we’ve eased off of 
the implicit conversions, we still left the as operator with the ability to 
force the conversions. This complicates the meaning of as: normally, it just 
provides type context, but it also has the power to force bridging conversions. 
These meanings are often at odds:

// `NSNumber` is `ExpressibleByIntegerLiteral`, so this gives type context to 
the literal 0
// and is equivalent to `NSNumber(integerLiteral: 0)`
0 as NSNumber

// `x` already has type `Int`, so this forces the bridging conversion and is 
equivalent to
// `_bridgeToObjectiveC(x)` (and thereby gives you a different kind of 
`NSNumber`!)
let x: Int = 0
x as NSNumber
Aside from the complexity and non-portability of this behavior, this is also 
inconsistent with the Swift naming conventions, which recommend that 
conversions between related types be presented as initializers. Additionally, 
the bridging conversions often have specialized behavior for performance or 
semantic reasons that aren’t intended to be exposed in the normal API of either 
type (for example, bridging a Swift number type to NSNumber produces a 
“type-preserving” instance of NSNumber so that the bridge doesn’t lose type 
information, even though NSNumber’s own API presents a type-agnostic numeric 
object). Therefore, I propose that we remove the bridging behavior from as, and 
provide APIs for conversion where they don’t yet exist. as is purely a 
compile-time construct with no runtime interaction, so the Swift 3 
compatibility and ABI issues are much simpler than they are when runtime 
casting behavior becomes involved.

Warning on is/as?/as! casts that statically induce bridging

Without changing the runtime behavior of casting, we could still discourage 
users from using dynamic casting to perform bridging conversions when it’s 
statically evident that a bridging conversion is the only way a cast succeeds. 
For example:

func abuseBridgingCasts(on object: AnyObject) {
// warning: dynamic cast requires a bridging conversion; use 
`Int(bridgedFrom:)` instead
let _ = object as? Int
}
This wouldn’t be perfect, since we wouldn’t be able to warn about fully dynamic 
casts, but it could help encourage users to write portable code that doesn’t 
rely on the Objective-C bridge in common situations.

Limiting when the runtime allows bridging in dynamic casts

Ideally, we would be able to change runtime dynamic casting itself to not 
involve bridging. However, as I mentioned above, there are at least two 
situations where bridging dynamic casts are necessary to meet design 
requirements:

To maintain compatibility with Swift 3 code
For dynamic-casting Anys that were bridged from an Objective-C id, since we 
don’t know statically whether a bridge to any particular Swift type is needed
However, neither of these is an insurmountable barrier. For Swift 3 
compatibility, if nothing else, we could ship a parallel set of runtime entry 
points for dynamic casting with the Swift 3 behavior that would be used when 
compiling code in Swift 3 mode (and those entry points could possibly be 
banished to a separate compatibility dylib to avoid weighing down the 
ABI-stable Swift runtime forever). For id-as-Any bridging, existentials could 
potentially carry a bit to indicate whether casting out of that particular 
value should admit bridging casts. Doing that has complications of its 
own—having otherwise equivalent Any values have different behavior is 
undeniably weird—but, if we can keep the behavior isolated to code that 
directly interfaces with ObjC, I think it’s worth investigating in the interest 
of making the overall language more predictable.

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

Re: [swift-evolution] 'T != Type' in where clause

[David Sweeris via swift-evolution]

> On Mar 1, 2017, at 18:55, Joe Groff  wrote:
> 
> 
>> On Mar 1, 2017, at 5:27 PM, David Sweeris  wrote:
>> 
>> 
>>> On Feb 28, 2017, at 09:01, Joe Groff  wrote:
>>> 
>>> 
 On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution 
  wrote:
 
 + all the 1s, along with something like "where !(T: Foo)"
>>> 
>>> This is an impossible constraint to enforce, since anyone can extend any 
>>> type to conform to Foo.
>> 
>> Only for protocols, right? I mean, as far as I know, you can’t declare a 
>> superclass in an extension.
>> 
>> I've been thinking about this for, well, about a day and a half, and I don't 
>> understand why it’s a problem. Wouldn’t any concrete type’s conformance 
>> propagate through the type system? How else would generic functions deal 
>> with types being extended outside the generic function’s module?
> 
> Protocol conformances are not intrinsic to the type in Swift. They're 
> effectively independent parameters to generic contexts that require them. The 
> caller from outside the generic function's model is responsible for choosing 
> a conformance to pass. There's no way to statically enforce that no such 
> conformance exists, and there's usually a better way to model things.

Ooo ok, thanks :-)

From a technical PoV, could we allow "where !(T: SomeClass)", since that 
doesn't involve protocols?

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

Re: [swift-evolution] 'T != Type' in where clause

[Joe Groff via swift-evolution]

> On Mar 1, 2017, at 5:27 PM, David Sweeris  wrote:
> 
> 
>> On Feb 28, 2017, at 09:01, Joe Groff  wrote:
>> 
>> 
>>> On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution 
>>>  wrote:
>>> 
>>> + all the 1s, along with something like "where !(T: Foo)"
>> 
>> This is an impossible constraint to enforce, since anyone can extend any 
>> type to conform to Foo.
> 
> Only for protocols, right? I mean, as far as I know, you can’t declare a 
> superclass in an extension.
> 
> I've been thinking about this for, well, about a day and a half, and I don't 
> understand why it’s a problem. Wouldn’t any concrete type’s conformance 
> propagate through the type system? How else would generic functions deal with 
> types being extended outside the generic function’s module?

Protocol conformances are not intrinsic to the type in Swift. They're 
effectively independent parameters to generic contexts that require them. The 
caller from outside the generic function's model is responsible for choosing a 
conformance to pass. There's no way to statically enforce that no such 
conformance exists, and there's usually a better way to model things.

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

[swift-evolution] [Accepted] SE-0104: Protocol-oriented integers

[Joe Groff via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md

The re-review of SE-0104 ran from February 17...25, 2017. The proposal is 
accepted with the following revisions:

- The root `Number` protocol should be renamed `Numeric`.
- Instead of using single-case enums as mock trailing argument labels, the 
`FullWidth` and `ReportingOverflow` variants should include that information in 
their basename:

multipliedFullWidth(by:)
dividingFullWidth(_:)

addingReportingOverflow(_:)
subtractingReportingOverflow(_:)
multipliedReportingOverflow(by:)
dividedReportingOverflow(by:)

- `popcount` should use the unabbreviated name `populationCount`.

The core team also observed that the proposed endianness-handling interfaces 
deserve further thought. In almost every known little-, big-, or mixed-endian 
format, converting to and from another endian are symmetric operations (going 
to and from big endian are the same operation, as are going to and from little 
endian), so there is no need for both sets of operations to be independent 
protocol requirements. The core team accepts the proposal as is for now, since 
it's a small corner of the larger proposal, but asks the authors for a 
follow-up proposal in this space.

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

Re: [swift-evolution] 'T != Type' in where clause

[Dave Abrahams via swift-evolution]

on Wed Mar 01 2017, Douglas Gregor  wrote:

>> On Mar 1, 2017, at 1:55 AM, Jonathan Hull  wrote:
>> 
>> What I would like is a way to specialize a generic function in a block of 
>> code: (Strawman syntax)
>> 
>>  if T is Int.self {
>>  //In this block of code T == Int
>>  }
>> 
>> It seems to me that the compiler might even be able to optimize this without 
>> a branch.  If there
> is a return in the block, then it might even be able to throw away all the 
> code after it for the Int
> version of the function.
>
> We’ve been calling this “type refinement”. Essentially, within some
> lexical context (the “if” here) we can assert additional properties on
> a type or one specific (constant) values and take advantage of those
> properties, as you’ve done with T == Int.
>
> It’s a plausible language feature, and could be useful. There’s
> certainly some precedent for it: C++17 adds something similar with
> “constexpr if”, albeit in their non-separately-type-checked template
> instantiation model.
>
> It’s a nontrivial language feature that’s well out of scope for Swift 4.

Huh?  This totally works:

  extension Optional {  
  
func goo() -> Int { 
  return Wrapped.self is Int.Type ? 1 : 0
}   
 
  }

  func rue() -> Int {
return (nil as Bool?).goo() + (nil as Int?).goo()
  }

  /* rue optimizes down to:

  .private_extern   __TF1x3rueFT_Si
  .globl__TF1x3rueFT_Si
  .p2align  4, 0x90
  __TF1x3rueFT_Si:
  pushq %rbp
  movq  %rsp, %rbp
  movl  $1, %eax
  popq  %rbp
  retq
  */

  print(rue())

What am I missing?
-- 
-Dave

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

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Pyry Jahkola via swift-evolution]

I guess I should also include the example where the user actually wanted the 
oldValue to be "x":

if case let .two(newValue, value) = example, value == oldValue { ... }

No surprises there, even if another conditional is required.

— Pyry

> On 1 Mar 2017, at 22.53, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Erica,
> 
> Instead of going into all these lengths introducing new syntax, why not 
> simply turn it into a warning when a `case let` binding shadows an existing 
> variable with the exact same type (which supposedly also conforms to 
> Equatable)?
> 
> Examples, including how to silence the said warning:
> 
> enum Value { case one(T), two(T, T), three(T, T, T) }
> 
> let example: Value = .two("a", "b")
> let oldValue = "x"
> // (Besides, you probably intended `oldValue` to be a `Character` in your
> // example. Well, it's a `String` in mine.)
> 
> if case let .two(newValue, oldValue) = example { ... }
> // 
> // warning: 'oldValue' shadows an existing variable of same type 'String'
> 
> if case let .two(newValue, (oldValue)) = example { assert(oldValue == 
> "b") }
> // Ok, adding extra parentheses silences the warning.
> 
> if case let .one(example) = example { ... }
> // Ok, because there's no way the author would equate the `example: 
> String`
> // in the LHS to the `example: Value` of the RHS.
> 
> let maybe: Optional = "perhaps"
> if case let maybe? = maybe { ... }
> if case let .some(maybe) = maybe { ... }
> // Again, none of these examples would be affected by the warning, because
> // the `maybe: String` bound in the `case let` has a different type than
> // the `maybe: String?` in the outer scope.
> 
> Personally, I do like the convenience that I can bind several variables with 
> one `let` keyword in a case expression. And I can't see the appeal to making 
> `~=`, let alone a completely new special-syntax assignment operator, more 
> prominent in Swift.
> 
> — Pyry
> 
>> On 28 Feb 2017, at 21.01, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> The following draft proposal addresses one matter of substance (eliminating 
>> edge case errors by adopting at-site conditional binding) and one of style 
>> (using the pattern match operator consistently). Its discussion was deferred 
>> from Phase 1 and remains in a fairly early stage. Your feedback will help me 
>> decide whether this is a proposal I want to keep developing or one that I 
>> should set aside and focus on other matters. Thank you. -- E
>> 
>> The work-in-progress gist is here:  
>> https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c 
>>  
>> 
>> Simplifying case syntax
>> 
>> Proposal: TBD
>> Author: Erica Sadun 
>> Status: TBD
>> Review manager: TBD
>>  
>> Introduction
>> 
>> This proposal re-architects case syntax grammar to reduce potential errors 
>> and simplify unwrapping enumerations. 
>> 
>> Swift-evolution thread: [Pitch] Reimagining guard case/if case 
>> 
>>  
>> Motivation
>> 
>> In its current design, Swift case binding suffers from two weaknesses.
>> 
>> Mixed external and internal let/var binding may introduce errors from 
>> uncommon edge cases.
>> Real-world users may not consider the parallel construction between if 
>> case/guard case with switchstatements or naturally connect the two layouts.
>>  
>> Internal
>>  Case Binding
>> 
>> When pattern matching, it's common to bind a variable or constant. It's 
>> uncommon but legal to use a bound value as an argument. Adopting an "always 
>> explicit, always within the parentheses" rule adds consistency and safety to 
>> Swift. 
>> 
>> Consider the following enumeration and values:
>> 
>> // An enum with one, two, or three associated values
>> enum Value { case one(T), two(T, T), three(T, T, T) }
>> 
>> // An example with two associated values
>> let example2: Value = .two("a", "b")
>> 
>> // A bound symbol
>> let oldValue = "x"
>> This code's goal is to conditionally bind newValue and pattern match the 
>> value stored in the oldValue symbol. The first example succeeds. The second 
>> example compiles and runs but does not match the coder's intent. Using an 
>> external letcreates a new oldValue shadow instead of pattern matching 
>> oldValue's stored value.
>> 
>> // Safe
>> if case .two(let newValue, oldValue) = example2 { 
>> ... 
>> }
>> 
>> // Syntactically legal but incorrect
>> if case let .two(newValue, oldValue) = 

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Pyry Jahkola via swift-evolution]

Erica,

Instead of going into all these lengths introducing new syntax, why not simply 
turn it into a warning when a `case let` binding shadows an existing variable 
with the exact same type (which supposedly also conforms to Equatable)?

Examples, including how to silence the said warning:

enum Value { case one(T), two(T, T), three(T, T, T) }

let example: Value = .two("a", "b")
let oldValue = "x"
// (Besides, you probably intended `oldValue` to be a `Character` in your
// example. Well, it's a `String` in mine.)

if case let .two(newValue, oldValue) = example { ... }
// 
// warning: 'oldValue' shadows an existing variable of same type 'String'

if case let .two(newValue, (oldValue)) = example { assert(oldValue == "b") }
// Ok, adding extra parentheses silences the warning.

if case let .one(example) = example { ... }
// Ok, because there's no way the author would equate the `example: String`
// in the LHS to the `example: Value` of the RHS.

let maybe: Optional = "perhaps"
if case let maybe? = maybe { ... }
if case let .some(maybe) = maybe { ... }
// Again, none of these examples would be affected by the warning, because
// the `maybe: String` bound in the `case let` has a different type than
// the `maybe: String?` in the outer scope.

Personally, I do like the convenience that I can bind several variables with 
one `let` keyword in a case expression. And I can't see the appeal to making 
`~=`, let alone a completely new special-syntax assignment operator, more 
prominent in Swift.

— Pyry

> On 28 Feb 2017, at 21.01, Erica Sadun via swift-evolution 
>  wrote:
> 
> The following draft proposal addresses one matter of substance (eliminating 
> edge case errors by adopting at-site conditional binding) and one of style 
> (using the pattern match operator consistently). Its discussion was deferred 
> from Phase 1 and remains in a fairly early stage. Your feedback will help me 
> decide whether this is a proposal I want to keep developing or one that I 
> should set aside and focus on other matters. Thank you. -- E
> 
> The work-in-progress gist is here:  
> https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c 
>  
> 
> Simplifying case syntax
> 
> Proposal: TBD
> Author: Erica Sadun 
> Status: TBD
> Review manager: TBD
>  
> Introduction
> 
> This proposal re-architects case syntax grammar to reduce potential errors 
> and simplify unwrapping enumerations. 
> 
> Swift-evolution thread: [Pitch] Reimagining guard case/if case 
> 
>  
> Motivation
> 
> In its current design, Swift case binding suffers from two weaknesses.
> 
> Mixed external and internal let/var binding may introduce errors from 
> uncommon edge cases.
> Real-world users may not consider the parallel construction between if 
> case/guard case with switchstatements or naturally connect the two layouts.
>  
> Internal
>  Case Binding
> 
> When pattern matching, it's common to bind a variable or constant. It's 
> uncommon but legal to use a bound value as an argument. Adopting an "always 
> explicit, always within the parentheses" rule adds consistency and safety to 
> Swift. 
> 
> Consider the following enumeration and values:
> 
> // An enum with one, two, or three associated values
> enum Value { case one(T), two(T, T), three(T, T, T) }
> 
> // An example with two associated values
> let example2: Value = .two("a", "b")
> 
> // A bound symbol
> let oldValue = "x"
> This code's goal is to conditionally bind newValue and pattern match the 
> value stored in the oldValue symbol. The first example succeeds. The second 
> example compiles and runs but does not match the coder's intent. Using an 
> external letcreates a new oldValue shadow instead of pattern matching 
> oldValue's stored value.
> 
> // Safe
> if case .two(let newValue, oldValue) = example2 { 
> ... 
> }
> 
> // Syntactically legal but incorrect
> if case let .two(newValue, oldValue) = example2 { 
> ... 
> }
(…)

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[Hooman Mehr via swift-evolution]

Similar observation on my side as well. Certainly it is better to specify the 
class constrain (or the type alias that has the class constrain) first because 
(sub)class constrain is the most determining factor about the nature of the 
declaration, but I think it is too hard to enforce properly when we have left 
type alias door wide open.

> On Mar 1, 2017, at 12:01 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> A good and necessary enhancement. My only objection is to the ordering 
>> rules—I'm not convinced that they pull their weight, especially given that 
>> typealiases can be used to introduce class constraints that aren't in the 
>> leftmost position. It's a lot of rules and strictures for a dubious benefit. 
> 
> I made a similar comment in the discussion thread.  I don’t feel strongly 
> enough to argue over it, but it does feel like a rather arbitrary limitation.
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Sent from my iPhone
>> 
>> On Feb 28, 2017, at 1:11 PM, Douglas Gregor > > wrote:
>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0156 "Class and Subtype existentials" begins now and runs 
>>> through March 7, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md
>>>  
>>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[David Hart via swift-evolution]

> On 1 Mar 2017, at 21:20, Matthew Johnson  wrote:
> 
> 
>> On Mar 1, 2017, at 2:16 PM, David Hart > > wrote:
>> 
>> 
>> 
>> On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> 
 On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
 A good and necessary enhancement. My only objection is to the ordering 
 rules—I'm not convinced that they pull their weight, especially given that 
 typealiases can be used to introduce class constraints that aren't in the 
 leftmost position. It's a lot of rules and strictures for a dubious 
 benefit. 
>>> 
>>> I made a similar comment in the discussion thread.  I don’t feel strongly 
>>> enough to argue over it, but it does feel like a rather arbitrary 
>>> limitation.
>> 
>> Same reasoning for class being the first in the inheritance/conformance 
>> list: it allows you to quickly read a list and see if there is a class where 
>> you expect it. The fact that one may come from a typealias is a different 
>> story: it's the difference between being able to quickly read an expression 
>> and understanding the whole function it's contained in.
> 
> Yep, I understand this.  The difference is that in the inheritance list if 
> there is a class present it must always be explicitly declared.  This means 
> you can always tell whether a class is involved by looking at the first item 
> in the list.  That is not the case when existential are composed.  If you 
> can’t rely on this in all cases the limitation feels somewhat arbitrary.
> 
> That said, it’s not a big deal.  I appreciate the proposal very much! :)

Yeah, it’s a detail :) Just trying to describe my thought process.

>> 
 
 -- 
 Brent Royal-Gordon
 Sent from my iPhone
 
 On Feb 28, 2017, at 1:11 PM, Douglas Gregor > wrote:
 
> Hello Swift community,
> 
> The review of SE-0156 "Class and Subtype existentials" begins now and 
> runs through March 7, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.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/0156-subclass-existentials.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-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 
 

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Erica Sadun via swift-evolution]

> On Mar 1, 2017, at 11:46 AM, Matthew Johnson  wrote:
>>> 
>>> I agree that the ambiguity created by moving `let` outside the local =
>>> binding context is problematic.  I alway place `let` immediately =
>>> alongside the binding for this reason. =20
>>> 
>>> In design 2 do you disallow matching a value using an existing name?  If =
>>> so, how do users match values bound to an existing name?  Or is that =
>>> just not possible?  I would oppose design 2 if it=E2=80=99s not =
>>> possible.
>> 
>> It shadows, just like it currently does
> 
> In that case I oppose design 2.  If we're going to change this let's fix it 
> and remove the ambiguity (from a reader's perspective when they don't know 
> the rule).
> 

I don't mind dropping design 2. It was added to the conversation just as we 
stopped 
discussing this the first time. Was trying to pick up with all the conversation 
intact.


>> 
>>> Both syntax designs you propose are very concise, but they look like an =
>>> operator which can take any value with the appropriate type on the left =
>>> hand side.  Unfortunately this isn=E2=80=99t the case (haha).  I think =
>>> that is problematic.  Did you consider this?  If so, what is the =
>>> rationale for this choice?
>>> 
>>> For example, a user might expect to be able to say:
>>> 
>>> // match is a boolean that is true if the pattern matched and fast =
>>> otherwise
>>> let match =3D .success(let value) ~=3D result
>>> 
>>> // we don=E2=80=99t know if `value` is bound here so we cannot allow the =
>>> above to be valid code.
>> 
>> Swift doesn't allow the results of conditional binding to be used as 
>> straightforward 
>> Booleans as they must be bound into a scope. `guard` cheats.
> 
> I understand that.  What I'm saying is that I can't think of any other binary 
> operator in Swift whose result cannot be assigned to a name.  For that reason 
> I am not convinced we should adopt the syntax you propose.  This *is not* a 
> normal binary operator expression so it shouldn't look like one.

How are you with design 1, my original design?

> 
>> 
>> -- E
>> 
>> 
>>> 
>>> href=3D"mailto:swift-evolution@swift.org; =
>>> class=3D"">swift-evolution@swift.org>> class=3D"">https://lists.swift.org/mailman/listinfo/swift-evolution>> class=3D"">>> class=3D"">=
>>> 
>>> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812--
>> 
> 

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[David Hart via swift-evolution]

> On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> A good and necessary enhancement. My only objection is to the ordering 
>> rules—I'm not convinced that they pull their weight, especially given that 
>> typealiases can be used to introduce class constraints that aren't in the 
>> leftmost position. It's a lot of rules and strictures for a dubious benefit. 
> 
> I made a similar comment in the discussion thread.  I don’t feel strongly 
> enough to argue over it, but it does feel like a rather arbitrary limitation.

Same reasoning for class being the first in the inheritance/conformance list: 
it allows you to quickly read a list and see if there is a class where you 
expect it. The fact that one may come from a typealias is a different story: 
it's the difference between being able to quickly read an expression and 
understanding the whole function it's contained in.

>> 
>> -- 
>> Brent Royal-Gordon
>> Sent from my iPhone
>> 
>>> On Feb 28, 2017, at 1:11 PM, Douglas Gregor  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of SE-0156 "Class and Subtype existentials" begins now and runs 
>>> through March 7, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.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/0156-subclass-existentials.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-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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[Brent Royal-Gordon via swift-evolution]

A good and necessary enhancement. My only objection is to the ordering 
rules—I'm not convinced that they pull their weight, especially given that 
typealiases can be used to introduce class constraints that aren't in the 
leftmost position. It's a lot of rules and strictures for a dubious benefit. 

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Feb 28, 2017, at 1:11 PM, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0156 "Class and Subtype existentials" begins now and runs 
> through March 7, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.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/0156-subclass-existentials.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-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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[Matthew Johnson via swift-evolution]

> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> A good and necessary enhancement. My only objection is to the ordering 
> rules—I'm not convinced that they pull their weight, especially given that 
> typealiases can be used to introduce class constraints that aren't in the 
> leftmost position. It's a lot of rules and strictures for a dubious benefit. 

I made a similar comment in the discussion thread.  I don’t feel strongly 
enough to argue over it, but it does feel like a rather arbitrary limitation.

> 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone
> 
> On Feb 28, 2017, at 1:11 PM, Douglas Gregor  > wrote:
> 
>> Hello Swift community,
>> 
>> The review of SE-0156 "Class and Subtype existentials" begins now and runs 
>> through March 7, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.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/0156-subclass-existentials.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-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] [Draft] scope-based submodules

[David Hart via swift-evolution]

Wonderful comments. I really enjoy your take on submodules which keeps most of 
the power while keeping the simplicity. Comments below:


Sent from my iPhone

On 1 Mar 2017, at 07:55, Brent Royal-Gordon via swift-evolution 
 wrote:

>> On Feb 24, 2017, at 11:34 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> Scope-based submodules
>> 
>>• Proposal: SE-
>>• Authors: Matthew Johnson
>>• Review Manager: TBD
>>• Status: Awaiting review
> 
> Well, this is certainly comprehensive! Sorry about the delay in answering; 
> I've been hosting a house guest and haven't had a lot of free time.
> 
>> The primary goal of this proposal are to introduce a unit of encapsulation 
>> within a module that is larger than a file as a means of adding explicit 
>> structure to a large program. All other goals are subordinate to this goal 
>> and should be considered in light of it. 
> 
> I agree with this as the primary goal of a submodule system.
> 
>> Some other goals of this proposal are:
>> 
>>• Submodules should help us to manage and understand the internal 
>> dependencies of a large, complex system.
>>• Submodules should be able to collaborate with peer submodules without 
>> necessarily being exposed to the rest of the module.
>>• A module should not be required to expose its internal submodule 
>> structure to users when symbols are exported.
>>• It should be possible to extract a submodule from existing code with 
>> minimal friction. The only difficulty should be breaking any circular 
>> dependencies.
> 
> One goal I don't see mentioned here is "segment the API surface exposed to 
> importing code". The `UIGestureRecognizerSubclass` use case has been 
> thoroughly discussed, but I think there are probably a lot of cases where 
> there are two "sides" to an API and it'd often be helpful to hide one unless 
> it's needed. `URLProtocol` and `URLProtocolClient` come to mind; the many 
> weird little classes and symbols related to `NSAtomicStore` and 
> `NSIncrementalStore` might be another.
> 
> (I'm not necessarily suggesting that the Foundation and Core Data overlays 
> should move these into submodules—I'm suggesting that, if they were 
> implemented in a Swift with a submodule feature, they would be candidates for 
> submodule encapsulation.)
> 
>> Submodule names form a hierarchical path:
>> 
>>• The fully qualified name of the submodule specified by 
>> Submodule.InnerSubmodule is: MyModuleName.Submodule.InnerSubmodule.
>>• In this example, InnerSubmodule is a child of Submodule.
>>• A submodule may not have the same name as any of its ancestors. This 
>> follows the rule used by types.
> 
> Does being in a nested submodule have any semantic effect, or is it just a 
> naming trick?
> 
>> Submodules may not be extended. They form strictly nested scopes.
>> 
>>• The only way to place code in a submodule is with a submodule 
>> declaration at the top of a file.
>>• All code in a file exists in a single submodule.
> 
> I'm a big supporter of the 1-to-N submodule-to-file approach.

Agreed.

>> There are several other ways to specify which submodule the top-level scope 
>> of a file is in. All of these alternatives share a crucial problem: you 
>> can’t tell what submodule your code is in by looking at the file. 
>> 
>> The alternatives are:
>> 
>>• Use a manifest file. This would be painful to maintain.
>>• Use file system paths. This is too tightly coupled to physical 
>> organization. Appendix A discusses file system independence in more detail.
>>• Leave this up to the build system. This makes it more difficult for a 
>> module to support multiple build systems.
> 
> I'm going to push back on this a little. I don't like the top-of-file 
> `submodule` declaration for several reasons:
> 
>1. Declarations in a Swift file are almost always order-independent. There 
> certainly aren't any that must be the first thing in the file to be valid.
> 
>2. Swift usually keeps configuration stuff out of source files so you can 
> copy and paste snippets of code or whole files around with minimum fuss. 
> Putting `submodule` declarations in files means that developers would need to 
> open and modify those files if they wanted to copy them to a different 
> project. (It's worth noting that your own goal of making it easy to extract 
> submodules into separate modules is undermined by submodule declarations 
> inside files.)
> 
>3. However you're organizing your source code—whether in the file system, 
> an IDE project, or whatever else—it's very likely that you will end up 
> organizing files by submodule. That means either information about submodules 
> will have to be specified twice—once in a canonical declaration and again in 
> source file organization—and kept in sync, or IDEs and tooling will have to 
> interpret the `submodule` declarations in source files and reflect that 
> 

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Feb 28, 2017, at 2:17 PM, Erica Sadun  wrote:
> 
> 
>> On Feb 28, 2017, at 12:19 PM, Matthew Johnson  wrote:
>> 
>> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812
>> Content-Transfer-Encoding: quoted-printable
>> Content-Type: text/plain;
>>charset=utf-8
>> 
>> I agree that the ambiguity created by moving `let` outside the local =
>> binding context is problematic.  I alway place `let` immediately =
>> alongside the binding for this reason. =20
>> 
>> In design 2 do you disallow matching a value using an existing name?  If =
>> so, how do users match values bound to an existing name?  Or is that =
>> just not possible?  I would oppose design 2 if it=E2=80=99s not =
>> possible.
> 
> It shadows, just like it currently does

In that case I oppose design 2.  If we're going to change this let's fix it and 
remove the ambiguity (from a reader's perspective when they don't know the 
rule).

> 
>> Both syntax designs you propose are very concise, but they look like an =
>> operator which can take any value with the appropriate type on the left =
>> hand side.  Unfortunately this isn=E2=80=99t the case (haha).  I think =
>> that is problematic.  Did you consider this?  If so, what is the =
>> rationale for this choice?
>> 
>> For example, a user might expect to be able to say:
>> 
>> // match is a boolean that is true if the pattern matched and fast =
>> otherwise
>> let match =3D .success(let value) ~=3D result
>> 
>> // we don=E2=80=99t know if `value` is bound here so we cannot allow the =
>> above to be valid code.
> 
> Swift doesn't allow the results of conditional binding to be used as 
> straightforward 
> Booleans as they must be bound into a scope. `guard` cheats.

I understand that.  What I'm saying is that I can't think of any other binary 
operator in Swift whose result cannot be assigned to a name.  For that reason I 
am not convinced we should adopt the syntax you propose.  This *is not* a 
normal binary operator expression so it shouldn't look like one.

> 
> -- E
> 
> 
>> 
>> href=3D"mailto:swift-evolution@swift.org; =
>> class=3D"">swift-evolution@swift.org> class=3D"">https://lists.swift.org/mailman/listinfo/swift-evolution> class=3D"">> class=3D"">=
>> 
>> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812--
> 

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

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Jonathan Hull via swift-evolution]

As I said before, I am happy with this proposal overall.

I just had a strange thought that I thought I should share before this goes 
through.  If we make ‘π’ an operator instead of identifier, then we would be 
able to write things like 3π directly.  For those of us with rational types, we 
could write (3/4)π.

Another option is that we could have it be a literal with an associated 
ExpressibleBy… protocol.

Just a thought I wanted to share...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Accepted] SE-0153: Compensate for the inconsistency of `@NSCopying`'s behaviour

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md
 


Hello Swift Community,

The review of SE-0153 "Compensate for the inconsistency of `@NSCopying`'s 
behaviour” ran from February 17…22, 2017. The proposal is accepted using the 
“compiler magic” approach, where the compiler will introduce the copy within 
the initialization to maintain the invariant that the stored property is always 
initialized with or set to a copy of the provided value.

Feedback from the review was mixed. There was general agreement that this was a 
real problem that does require a solution, but the discussion during the review 
slightly favored the more conservative approach of adding a warning in the 
compiler. This was based on two main concerns about introducing the copy within 
the initializer:

1) @NSCopying would act differently from didSet, the latter of which still 
would not be called within initializers, and
2) Concern that property behaviors would not be able to model the semantics 
described here.

The core team felt that @NSCopying needs to guarantee that the copy occurs 
under all circumstances, and that a change in language semantics here is 
warranted. Regarding concern (1), the core team felt that @NSCopying and didSet 
are different enough that different behavior is reasonable and expected. 
Regarding concern (2), the core team noted that property behaviors can model 
the new semantics by providing behaviors with an extra customization point that 
is invoked from within the initializer (and does not have access to “self”). 
Moreover, having this customization point in property behaviors will make 
concern (1) less acute, because property behaviors can and will differ in their 
initialization vs. setting behavior.

- Doug,
Review Manager

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

Re: [swift-evolution] 'T != Type' in where clause

[Joe Groff via swift-evolution]

> On Mar 1, 2017, at 1:55 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> What I would like is a way to specialize a generic function in a block of 
> code: (Strawman syntax)
> 
>   if T is Int.self {
>   //In this block of code T == Int
>   }
> 
> It seems to me that the compiler might even be able to optimize this without 
> a branch.

The compiler can already specialize away type checks like this (T.self is 
Int.Type will be reduced to a constant 'true' or 'false' when it specializes 
T). The type refinement part is missing, though, and I agree that it would be a 
useful addition.

-Joe

>  If there is a return in the block, then it might even be able to throw away 
> all the code after it for the Int version of the function.
> 
> Here is some actual (super ugly) code I wrote today.  I am unhappy with it 
> and looking to remove or improve it, but it is the best I can figure out at 
> the moment:
> 
> public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
> if T.self == Int.self {
> var op:((Int,Int)->Int)? = nil
> switch symbol {
> case "+": op = (+)
> case "-": op = (-)
> case "*","x","•": op = (*)
> case "/","÷": op = (/)
> default: break
> }
> if op != nil {
> return op as! ((T,T)->T)?
> }
> }
> // Function continues...
> 
> All this function does is take a string with a mathematical symbol in it and 
> return an operation associated with that symbol/type (if it exists).  In 
> addition to the built in ones here, the user is able to register custom 
> symbols and operations (the machinery for that is further down and less ugly).
> 
> Notice that I need to cast the operation back to (T,T)->T because it doesn’t 
> know that T is an Int here. It has an error saying the cast always fails, but 
> that isn’t true.
> 
> Ideally, I would be able to check if T is Numeric and then just return the 
> operator.  I have to do a bunch of extra work here to disambiguate for the 
> compiler. It needs me to call out specific types (like Int) individually and 
> then cast them back to T.
> 
> What I would like to do:
> 
> public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
> if T.self is Numeric {
> switch symbol {
> case "+": return (+)
> case "-": return (-)
> case "*","x","•": return (*)
> case "/","÷": return (/)
> default: break
> }
> }
> // Function continues…
> 
> or at least:
> 
> public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
> if T.self is Int {
> switch symbol {
> case "+": return (+)
> case "-": return (-)
> case "*","x","•": return (*)
> case "/","÷": return (/)
> default: break
> }
> }
> // Function continues...
> 
> Is it something that could be possible in a future version of Swift?  or am I 
> missing something obvious that is much better than this?
> 
> Thanks,
> Jon
> 
>> On Feb 28, 2017, at 2:15 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Feb 28, 2017, at 2:00 PM, David Hart >> > wrote:
>>> 
>>> 
 On 28 Feb 2017, at 22:39, Douglas Gregor via swift-evolution 
 > wrote:
 
 
> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution 
> > wrote:
> 
> +1
> I would also welcome to be able to use "or" and "and" logical operators 
> (not only the not operator) on these constraints.
 
 You already have “and’ constraints: it’s what you get out of the 
 comma-separated list of constraints in a where clause, or the “&” 
 composition syntax.
 
> I have sometimes generic functions whose code is identical but is written 
> twice: first with 'where T=P1' and then with 'where T=P2', being able to 
> write for instance 'where T=(P1 or P2)' would be very handy IMO.
> One could often argue that additional protocols and extensions could be 
> defined as a workaround to the situation I just mentioned but it seems 
> often a bit of an overkill to me when you only have a couple of functions 
> with that combination of requirements.
 
 “Or” constraints are a nonstarter for me, because you can’t meaningfully 
 type-check a generic function that uses “or” constraints: the problem goes 
 exponential in the number of “or” constraints and the meaning of the 
 function can change considerably depending on which set of terms are 
 satisfied—in which case you have ambiguities again!
 
 Whenever 

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

[Joe Groff via swift-evolution]

> On Feb 28, 2017, at 10:39 PM, David Hart  wrote:
> 
>> 
>> On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement 
>> of 'P' to make it interesting ('C & Q’).
> 
> Could generic specialisation be disallowed in constraints? I need to think 
> about this.

I don't think there's any added complexity alone in allowing generic base class 
constraints in existentials, since we already support `>` as a 
constraint on a generic parameter. It's the interaction between classes and 
protocols with associated types that's interesting. You don't even need a 
generic class:

protocol P { associatedtype T; func foo(_: T) }
class C: P { func foo(_: Int) {} }

protocol Q: P {}

let x: C & Q

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

Re: [swift-evolution] [Discussion] Simplifying case syntax

[David Hart via swift-evolution]

Would you agree with the following arguments?

> On 1 Mar 2017, at 15:57, Xiaodi Wu  wrote:
> 
> The criteria for a source-breaking change in Swift 4 are as follows:
> 
> - The existing syntax/API being changed must be actively harmful.

The current pattern matching syntax is inconsistent which makes it hard even 
for experts to get correct (I often have to check it up) and is confusing for 
newcomers because of the use of the assignment operator. Both of these 
arguments tend to show that the existing syntax is actively harmful.

> - The new syntax/API must clearly be better and not conflict with existing 
> Swift syntax.

Design 1:
• fixes the inconsistencies in optional pattern binding between switch and 
if/guard
• reduces the number of different positions the let keyword can be in for enum 
matching, improving its learnability
• uses an existing operator which clarifies the pattern matching intent for 
newcomers

> - There must be a reasonably automatable migration path for existing code.

All these changes affect syntax on expressions and can be migrated like by line 
without looking at the environnement of the piece of code, simplifying its 
migration.

>> On Wed, Mar 1, 2017 at 02:30 Goffredo Marocchi  wrote:
>> I would think that removing confusion and simplifying + rationalising the 
>> syntax IS the definition of a breaking change justified :). I do not see how 
>> Erica's proposal is in any way contrary to the philosophy behind the 
>> language or is removing anything people really depend on now (in terms of 
>> expressive ability).
>> 
>> This should be nowhere near as controversial as the removal of pre and post 
>> increments and C style for loops, quite a slam dunk actually.
>> 
>> Sent from my iPhone
>> 
>>> On 28 Feb 2017, at 23:45, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Agree. Design 1 seems like an improvement over the status quo. Barring 
>>> unexpected downsides to this, it's then a question of whether the 
>>> improvements are large enough to justify a breaking change.
>>> 
>>> 
 On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution 
  wrote:
 I’m happy that someone is trying to fix this small wart in the language. 
 I’ve always wanted something like Design 1. It makes sense because we are 
 already used to the pattern matching operator and we finally fix the 
 inconsistencies between if/guard and switch.
 
 On 28 Feb 2017, at 20:01, Erica Sadun via swift-evolution 
  wrote:
 
 The following draft proposal addresses one matter of substance 
 (eliminating edge case errors by adopting at-site conditional binding) and 
 one of style (using the pattern match operator consistently). Its 
 discussion was deferred from Phase 1 and remains in a fairly early stage. 
 Your feedback will help me decide whether this is a proposal I want to 
 keep developing or one that I should set aside and focus on other matters. 
 Thank you. -- E
 
 The work-in-progress gist is here:  
 https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c 
 
 Simplifying case syntax
 Proposal: TBD
 Author: Erica Sadun
 Status: TBD
 Review manager: TBD
 Introduction
 
 This proposal re-architects case syntax grammar to reduce potential errors 
 and simplify unwrapping enumerations. 
 
 Swift-evolution thread: [Pitch] Reimagining guard case/if case
 
 Motivation
 
 In its current design, Swift case binding suffers from two weaknesses.
 
 Mixed external and internal let/var binding may introduce errors from 
 uncommon edge cases.
 Real-world users may not consider the parallel construction between if 
 case/guard case with switchstatements or naturally connect the two layouts.
 Internal Case Binding
 
 When pattern matching, it's common to bind a variable or constant. It's 
 uncommon but legal to use a bound value as an argument. Adopting an 
 "always explicit, always within the parentheses" rule adds consistency and 
 safety to Swift. 
 
 Consider the following enumeration and values:
 
 // An enum with one, two, or three associated values
 enum Value { case one(T), two(T, T), three(T, T, T) }
 
 // An example with two associated values
 let example2: Value = .two("a", "b")
 
 // A bound symbol
 let oldValue = "x"
 This code's goal is to conditionally bind newValue and pattern match the 
 value stored in the oldValue symbol. The first example succeeds. The 
 second example compiles and runs but does not match the coder's intent. 
 Using an external letcreates a new oldValue shadow instead of pattern 
 matching oldValue's stored value.
 
 // Safe
 if case .two(let newValue, oldValue) = example2 { 
 ... 
 }

Re: [swift-evolution] 'T != Type' in where clause

[David Sweeris via swift-evolution]

> On Feb 28, 2017, at 09:38, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I also thought about the Either type.
> 
> enum Either where A != B {
> case -> A
> case -> B
> }

I was thinking about using it as a workaround for not having typed throws:
protocol MyErrorType: Error {...} // all my custom errors conform to this
enum MyError : Error where !(U: FixableError) {
case myError(T)
case otherError(U)
}

Which ensures that, if an instance of "MyError" is .otherError, the payload 
will actually be an other error (or at least not an error that originated with 
any of my code).

Seems like if the program logic is intended to ensure that something is only a 
value of an exact type and not some sort of subtype, there ought to be a way to 
express that to the type system.

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

Re: [swift-evolution] 'T != Type' in where clause

[Douglas Gregor via swift-evolution]

> On Mar 1, 2017, at 1:55 AM, Jonathan Hull  wrote:
> 
> What I would like is a way to specialize a generic function in a block of 
> code: (Strawman syntax)
> 
>   if T is Int.self {
>   //In this block of code T == Int
>   }
> 
> It seems to me that the compiler might even be able to optimize this without 
> a branch.  If there is a return in the block, then it might even be able to 
> throw away all the code after it for the Int version of the function.

We’ve been calling this “type refinement”. Essentially, within some lexical 
context (the “if” here) we can assert additional properties on a type or one 
specific (constant) values and take advantage of those properties, as you’ve 
done with T == Int.

It’s a plausible language feature, and could be useful. There’s certainly some 
precedent for it: C++17 adds something similar with “constexpr if”, albeit in 
their non-separately-type-checked template instantiation model.

It’s a nontrivial language feature that’s well out of scope for Swift 4.

- Doug

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

Re: [swift-evolution] [Draft] Fix Private Access Levels

[Joanna Carter via swift-evolution]

> For example, I had to split this class into multiple files using extensions:
> https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift
> I had to remove 'private' modifier from all variables and functions. Now 
> class implementation details are exposed to the entire module. 'Fileprivate' 
> was of no use in this situation. If there was an ability to mark them as 
> `private to type + extensions`, I would use this access level instead. In 
> fact, in 99% of use cases I needed that exact behavior and not 'internal to 
> module', so I also proposed making it the default.

I was used to using partial classes in C#, to separate partial concerns in a 
single type. Swift extensions give us similar behaviour but, at the moment, I 
would rather be programming in C# than Swift when it comes to visibility 
control.

> In other words, current visibility system doesn't work for my coding style 
> (splitting classes into multiple files), nor it will work after rolling back 
> private behavior. It could become useful if the concept could be exteded to 
> mean "fileprivate + its extensions private". It would allow protecting other 
> classes in the module from accessing implementation details of the current 
> class. It's sad that many people are opposed to this concept.
> 
> On separate 'scoped' access, I agree that it may be redundant.

I've still to get a grip on what is meant by 'scoped' access. The only way I 
see it is as a file/module based approach as opposed to a type based approach.

> To summarize, I propose reverting "private" to mean "fileprivate" but 
> extending it to extensions as well. This way both coding styles could be 
> used: putting everything in a single huge file or splitting the class into 
> multiple files or mixing these approaches. Ideally, I think it should be the 
> default access level leaving only "public" and "internal" keywords to be set 
> explicitly.

Certainly, if we can't have a dedicated "extensible" scope for this kind of 
scenario, then we, at least, need some way to limit visibility of "private" 
data to a type and its extensions ; so, as much as I really don't like the idea 
of extending private back to the fileprivate scope, extending private to mean 
inclusion of its extensions would be really welcome.

Internal is just simply too big for this kind of situation

--
Joanna Carter
Carter Consulting

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

Re: [swift-evolution] [Discussion] Simplifying case syntax

[Xiaodi Wu via swift-evolution]

The criteria for a source-breaking change in Swift 4 are as follows:

- The existing syntax/API being changed must be actively harmful.
- The new syntax/API must clearly be better and not conflict with existing
Swift syntax.
- There must be a reasonably automatable migration path for existing code.

On Wed, Mar 1, 2017 at 02:30 Goffredo Marocchi  wrote:

> I would think that removing confusion and simplifying + rationalising the
> syntax IS the definition of a breaking change justified :). I do not see
> how Erica's proposal is in any way contrary to the philosophy behind the
> language or is removing anything people really depend on now (in terms of
> expressive ability).
>
> This should be nowhere near as controversial as the removal of pre and
> post increments and C style for loops, quite a slam dunk actually.
>
> Sent from my iPhone
>
> On 28 Feb 2017, at 23:45, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Agree. Design 1 seems like an improvement over the status quo. Barring
> unexpected downsides to this, it's then a question of whether the
> improvements are large enough to justify a breaking change.
>
>
> On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m happy that someone is trying to fix this small wart in the language.
> I’ve always wanted something like Design 1. It makes sense because we are
> already used to the pattern matching operator and we finally fix the
> inconsistencies between if/guard and switch.
>
> On 28 Feb 2017, at 20:01, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The following draft proposal addresses one matter of substance
> (eliminating edge case errors by adopting at-site conditional binding) and
> one of style (using the pattern match operator consistently). Its
> discussion was deferred from Phase 1 and remains in a fairly early stage.
> Your feedback will help me decide whether this is a proposal I want to keep
> developing or one that I should set aside and focus on other matters. Thank
> you. -- E
>
> The work-in-progress gist is here:
> https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c
>
> Simplifying case syntax
>
>- Proposal: TBD
>- Author: Erica Sadun 
>- Status: TBD
>- Review manager: TBD
>
>
> 
> Introduction
>
> This proposal re-architects case syntax grammar to reduce potential errors
> and simplify unwrapping enumerations.
>
> Swift-evolution thread: [Pitch] Reimagining guard case/if case
> 
> 
> Motivation
>
> In its current design, Swift case binding suffers from two weaknesses.
>
>- Mixed external and internal let/var binding may introduce errors
>from uncommon edge cases.
>- Real-world users may not consider the parallel construction between if
>case/guard case with switchstatements or naturally connect the two
>layouts.
>
>
> Internal
> Case Binding
>
> When pattern matching, it's common to bind a variable or constant. It's
> uncommon but legal to use a bound value as an argument. Adopting an "always
> explicit, always within the parentheses" rule adds consistency and safety
> to Swift.
>
> Consider the following enumeration and values:
>
> // An enum with one, two, or three associated valuesenum Value { case 
> one(T), two(T, T), three(T, T, T) }
> // An example with two associated valueslet example2: Value = 
> .two("a", "b")
> // A bound symbollet oldValue = "x"
>
> This code's goal is to conditionally bind newValue and pattern match the
> value stored in the oldValue symbol. The first example succeeds. The
> second example compiles and runs but does not match the coder's intent.
> Using an external letcreates a new oldValue shadow instead of pattern
> matching oldValue's stored value.
>
> // Safe
> if case .two(let newValue, oldValue) = example2 {
> ...
> }
>
> // Syntactically legal but incorrect
> if case let .two(newValue, oldValue) = example2 {
> ...
> }
>
> In-parenthesis binding avoids accidental shadowing. It eliminates this
> class of error by adding let and var key words to each use point. This
> creates longer call sites but enumerations rarely contain more than three
> or four associated items.
>
> Adopting point-of-use binding enhances clarity and readability. Both if
> case let and if case var (plus case varand case let) may look like single
> compound keywords rather than a combination of two distinct actions to
> developers unfamiliar with this syntax.
>
> Pattern
> Matching with Conditional Binding
>

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

[Daniel Leping via swift-evolution]

Definitely +1

On Wed, 1 Mar 2017 at 12:59 Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

> On 28 Feb 2017, at 21:40, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>- What is your evaluation of the proposal?
>
> +1
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes. The problem it addresses is an almost daily annoyance when working
> with collections!
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes. In fact it removes the need for some very ugly workarounds that are
> currently in use within stdlib (and aren't full workarounds anyway).
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Been following the subject for a while, quick re-read of the latest
> 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] [Draft] Fix Private Access Levels

[Andrey Fidrya via swift-evolution]

> In the previous very long thread, many people acknowledged that type + its 
> extensions private was too complex for its own good. Do you have arguments 
> against that? And even if it was proposed, I think many people would be very 
> opposed to keeping scoped in that case. There would be too little difference 
> between the two to be worth it.

I've been following that thread. Yes, I'll try to present them:

For example, I had to split this class into multiple files using extensions:
https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift
 

I had to remove 'private' modifier from all variables and functions. Now class 
implementation details are exposed to the entire module. 'Fileprivate' was of 
no use in this situation. If there was an ability to mark them as `private to 
type + extensions`, I would use this access level instead. In fact, in 99% of 
use cases I needed that exact behavior and not 'internal to module', so I also 
proposed making it the default.

In other words, current visibility system doesn't work for my coding style 
(splitting classes into multiple files), nor it will work after rolling back 
private behavior. It could become useful if the concept could be exteded to 
mean "fileprivate + its extensions private". It would allow protecting other 
classes in the module from accessing implementation details of the current 
class. It's sad that many people are opposed to this concept.

On separate 'scoped' access, I agree that it may be redundant.

To summarize, I propose reverting "private" to mean "fileprivate" but extending 
it to extensions as well. This way both coding styles could be used: putting 
everything in a single huge file or splitting the class into multiple files or 
mixing these approaches. Ideally, I think it should be the default access level 
leaving only "public" and "internal" keywords to be set explicitly.

Regards,
Andrey



> On 21 Feb 2017, at 15:17, David Hart  wrote:
> 
>> 
>> On 21 Feb 2017, at 12:44, Andrey Fidrya > > wrote:
>> 
>> >Alternatives Considered:
>> >2. Deprecate fileprivate and modify the semantics of private to include 
>> >same-type extension scopes in the same module.
>> 
>> Imho, this is a better alternative.
>> 
>> I rarely implement class extensions in the same file. Most often they have 
>> their own files, like
>> MyClass+Search.swift
>> MyClass+SomethingElse.swift
>> 
>> Even in cases where implementing them in the same file makes sense, I'm not 
>> using current fileprivate modifier on variables because if I later have to 
>> implement an extension in a different file, I'll have to remove all these 
>> modifiers.
>> 
>> 
>> Also, I don't think internal is a good default choice... Even if private is 
>> changed back to mean "file private" or "class private", it will add a lot of 
>> visual noise... For proper access limitation, basically everything has to be 
>> marked "private". Compare:
>> 
>> class C {
>>   var a = 1
>>   var b = 2
>>   func f() { } 
>> }
>> 
>> to:
>> 
>> class C {
>>   private var a = 1
>>   private var b = 2
>>   private func f() { etc }
>> }
>> 
>> 
>> Also, in classes inheritance is denied by default, but variables have more 
>> open 'internal' access level by default.
>> It looks like an inconcistency to me. Users have to explicitly allow 
>> inheritance, but disallow access to variables.
>> 
>> 
>> +1 to the arguments about not mixing concepts (file or scope/type based). 
>> Personally I'd prefer scope/type only.
>> Also, fileprivate access doesn't play well with playgrounds and makes 
>> rearranging code harder.
>> 
>> 
>> If redesigning this from scratch, I'm thinking of this design:
>> 1. scoped (works like the current private)
>> 2. private (to the class + it's extensions inside the module) - and making 
>> it the default
>> 3. internal (to the module). Should be set only on variables where it's 
>> really needed (will be rarely used).
> 
> In the previous very long thread, many people acknowledged that type + its 
> extensions private was too complex for its own good. Do you have arguments 
> against that? And even if it was proposed, I think many people would be very 
> opposed to keeping scoped in that case. There would be too little difference 
> between the two to be worth it.
> 
>> One more argument for adding "scoped" access level:
>> if it will be allowed to declare variables in extensions of the same module 
>> in the future, having "scoped" would be very convenient as there can be 
>> multiple extensions in the same file.
>> 
>> 
>> Regards,
>> Andrey
>> 
>> 
>> 
>>> On 21 Feb 2017, at 09:58, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Hello list,
>>> 
>>> Matthew Johnson and I have been putting our proposals together towards a 

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

[Haravikk via swift-evolution]

> On 28 Feb 2017, at 21:40, John McCall via swift-evolution 
>  wrote:
> 
> What is your evaluation of the proposal?
+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes. The problem it addresses is an almost daily annoyance when working with 
collections!

> Does this proposal fit well with the feel and direction of Swift?
Yes. In fact it removes the need for some very ugly workarounds that are 
currently in use within stdlib (and aren't full workarounds anyway).

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

Been following the subject for a while, quick re-read of the latest proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] 'T != Type' in where clause

[Jonathan Hull via swift-evolution]

What I would like is a way to specialize a generic function in a block of code: 
(Strawman syntax)

if T is Int.self {
//In this block of code T == Int
}

It seems to me that the compiler might even be able to optimize this without a 
branch.  If there is a return in the block, then it might even be able to throw 
away all the code after it for the Int version of the function.

Here is some actual (super ugly) code I wrote today.  I am unhappy with it and 
looking to remove or improve it, but it is the best I can figure out at the 
moment:

public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
if T.self == Int.self {
var op:((Int,Int)->Int)? = nil
switch symbol {
case "+": op = (+)
case "-": op = (-)
case "*","x","•": op = (*)
case "/","÷": op = (/)
default: break
}
if op != nil {
return op as! ((T,T)->T)?
}
}
// Function continues...

All this function does is take a string with a mathematical symbol in it and 
return an operation associated with that symbol/type (if it exists).  In 
addition to the built in ones here, the user is able to register custom symbols 
and operations (the machinery for that is further down and less ugly).

Notice that I need to cast the operation back to (T,T)->T because it doesn’t 
know that T is an Int here. It has an error saying the cast always fails, but 
that isn’t true.

Ideally, I would be able to check if T is Numeric and then just return the 
operator.  I have to do a bunch of extra work here to disambiguate for the 
compiler. It needs me to call out specific types (like Int) individually and 
then cast them back to T.

What I would like to do:

public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
if T.self is Numeric {
switch symbol {
case "+": return (+)
case "-": return (-)
case "*","x","•": return (*)
case "/","÷": return (/)
default: break
}
}
// Function continues…

or at least:

public static func operation(symbol:String, type:T.Type)->((T,T)->T)?{
if T.self is Int {
switch symbol {
case "+": return (+)
case "-": return (-)
case "*","x","•": return (*)
case "/","÷": return (/)
default: break
}
}
// Function continues...

Is it something that could be possible in a future version of Swift?  or am I 
missing something obvious that is much better than this?

Thanks,
Jon

> On Feb 28, 2017, at 2:15 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On Feb 28, 2017, at 2:00 PM, David Hart > > wrote:
>> 
>> 
>>> On 28 Feb 2017, at 22:39, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution 
 > wrote:
 
 +1
 I would also welcome to be able to use "or" and "and" logical operators 
 (not only the not operator) on these constraints.
>>> 
>>> You already have “and’ constraints: it’s what you get out of the 
>>> comma-separated list of constraints in a where clause, or the “&” 
>>> composition syntax.
>>> 
 I have sometimes generic functions whose code is identical but is written 
 twice: first with 'where T=P1' and then with 'where T=P2', being able to 
 write for instance 'where T=(P1 or P2)' would be very handy IMO.
 One could often argue that additional protocols and extensions could be 
 defined as a workaround to the situation I just mentioned but it seems 
 often a bit of an overkill to me when you only have a couple of functions 
 with that combination of requirements.
>>> 
>>> “Or” constraints are a nonstarter for me, because you can’t meaningfully 
>>> type-check a generic function that uses “or” constraints: the problem goes 
>>> exponential in the number of “or” constraints and the meaning of the 
>>> function can change considerably depending on which set of terms are 
>>> satisfied—in which case you have ambiguities again!
>>> 
>>> Whenever this topic comes up, I like to point people at:
>>> 
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2161.pdf 
>>> 
>> Should we also follow Recommendation #2 and revert the P1 & P2 change to 
>> return to Any :) Half-joking.
> 
> That line of argument got thoroughly shot down in the core team meeting when 
> we discussed the introduction of the & operator for types.
> 
>   - Doug
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 

[swift-evolution] [Discussion] What is the future of tuples in Swift?

[Adrian Zubarev via swift-evolution]

Hi Swift community,

I’d love to discuss with you the future of tuples in Swift. I’m really curious 
whether tuples will ever evolve beyond their current state or not.

Last year we revamped custom operators with a whole new syntax in Swift, so why 
don’t we start a discussion on how tuples could evolve to enhance the language.

Currently tuples are a fixed and ordered set of types, which has only one 
syntactic sugar feature to provide a better way of accessing the stored vales. 
I was referring to labeled tuples. And that’s pretty much it what tuples 
provides for us up until now. Tuple is a primitive type, but so are structs, 
enums, string, character and number types in different languages. In Swift we 
have way more powerful primitive types, but we’d like to call them value types 
instead.

Could we make tuples as *extensible* value types?
Can we vectorize tuples with fixed and unbound length of types? Speaking of 
which, variadics share a similar fashion of providing an unbound ordered set of 
types, which could be more generalized with tuples. Beyond that, vectorized 
tuples could probably play well with generic variadics, and we also would have 
the ability to limit the number of types with tuple related constraints.
If a tuple contains a specific, ordered set of types we could probably make it 
conditional conforming to protocols like Sequence or Collection to easily 
convert it to an array or any other type that accepts such existential.
The following snippet is not a design of *new* tuples nor something I’d propose 
at this moment, but a simple sketch to memorize what we could do to tuples. 
However I’m not proposing to change the current syntax for tuples, lets call it 
_shorthand-syntax_ (label1: Int, String), but I’d like to open the door for an 
additional more flexible way to create tuples.

typealias MyTuple = tuple {
  T,
  Int,
  vector String,  // same as `String…`
  vector(10) Bool // fixed length of 10 booleans
}

typealias MyTuple = (T, Int, vector String, vector(10) Bool)

extension MyTuple : MyProtocol { ... }
Your feedback and ideas of the future of tuples is much appreciated.



-- 
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

[Ankit Aggarwal via swift-evolution]

Hi,

Thank you all for the feedback so far. I have updated the proposal:
https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md

The major changes are:

* Drop SystemPackageProvider struct upgrade.
* Drop the identity rule.
* Targets and Products will use factory methods.
* Rename VersionSetSpecifier to Requirement (because we also support
revision and branches and not just versions).
* Add a section on example manifests.

Note that there are collapsed examples and diffs in each proposed change.
Click "view example" to expand the examples.


On Wed, Mar 1, 2017 at 3:37 AM, Jens Nerup via swift-build-dev <
swift-build-...@swift.org> wrote:

> Hi Daniel,
>
> Thanks for the reply. Sorry I wasn't clear - by removal I actually meant
> remove pkgConfig from the Package, and introduce it in a custom build
> configuration (associated with a Target). I think pkgConfig and custom
> build configurations may fit nicely together. And you are absolutely right
> this is probably best suited for a follow on to the current manifest API
> redesign. Let's discuss that later and once again thank you for your quick
> reply.
>
> Regards,
>
> Jens
>
> On 28 Feb 2017, at 17.05, Daniel Dunbar  wrote:
>
>
> On Feb 28, 2017, at 12:28 AM, Jens Nerup  wrote:
>
> Hello Daniel,
>
> In general I’m really happy with the changes in the proposal and
> especially after you have incorporated the comments from David (Thanks
> David). In the proposal it is stated that the exclude section may be
> eliminated as soon as we have custom layouts. My question is: would
> pkgConfig be a candidate for removal as soon as we have support for custom
> build configurations?
>
>
> I don't think so, I don't think custom build configurations will be a
> replacement for the pkgConfig functionality, which is trying to gather
> settings from *outside* the package.
>
> I agree with the sentiment that it is an awkward thing to have the system
> module map package initializer, but unfortunately I think we may have to
> live with it for the time being. We have briefly discussed making it be a
> target not a package thing, and perhaps the move to using `.target()`
> should actually encourage us to do that, but that is probably something
> best done as a follow on to the manifest API redesign (as with exclude)
> given its limited scope.
>
>  - Daniel
>
>
> Regards,
>
> Jens
>
> On 28 Feb 2017, at 01.50, Daniel Dunbar via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hi David,
>
> We discussed the leading-dot & capitalization issue today again... this
> was already something we weren't really happy about, but had chosen to live
> with (using the "identity" rule to determine what was a type and what
> wasn't). However, as we talked it over more we:
> 1. Felt that for the product types, using .library vs .Library would be
> reasonable and consistent with a user model of thinking of these like enums
> (even though they won't actually be in practice, we will use factory
> functions on Product to make the dot work and keep the space extensible).
> 2. Realized that using .target would be a useful change to make now if we
> ever ended up needing to make the Targets array polymorphic (not something
> we plan to do now, but it never hurts to have it be extensible).
> so we decided to go ahead and revise to a model where we use leading-dot +
> lowercase for everything (except Package), including reverting
> SystemPackageProvider to the `.brew(...)` style syntax.
>
> Thanks for the feedback!
>  - Daniel
>
> On Feb 27, 2017, at 2:21 AM, Ankit Aggarwal via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hi David,
>
> Thanks for the feedback! Comments inline:
>
>
> On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
>> Was looking forward to this :) here are my comments:
>>
>> On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi all,
>>
>> Ankit, Daniel, Anders, Boris and I have a draft proposal in progress for
>> a Package.swift manifest API redesign for the Package Manager. We'll
>> welcome comments or discussion at this time. My hope is that we can get
>> this polished up and ready for evolution within the next week or so, but
>> we'll see how the conversation goes!
>>
>> You can see the proposal in progress at https://github.com/aciidb0m
>> b3r/swift-evolution/blob/manifest-api-redesign/proposal
>> s/-package-manager-manifest-api-redesign.md. I'm also including the
>> current version inline in this email.
>>
>> Thanks,
>>
>>- Rick
>>
>> # Package Manager Manifest API Redesign
>>
>> * Proposal: [SE-](-package-manager-manifest-api-redesign.md)
>> * Author: [Ankit Aggarwal](https://github.com/aciidb0mb3r)
>> * Review Manager: TBD
>> * Status: **Discussion**
>>
>> ## Introduction
>>
>> This is a proposal for redesigning the 

Re: [swift-evolution] [swit-evolution] [Review] SE-0156: Class and Subtype existentials

[Kevin Nattinger via swift-evolution]

> What is your evaluation of the proposal?
+0.9
The core of the proposal is unquestionably necessary to correct a serious 
deficiency in the expressivity of the type system, but I take issue with the 
arbitrary limitation of requiring the concrete type to be first and would give 
a full +1 to the core team accepting with the modification of removing that 
limitation.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Definitely. I’ve run into the issue this would solve several times in 
real-world applications.

> 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?
Basically a direct translation of the objc feature.

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

Followed and to some extent participated in the discussion, relatively quick 
read of the final proposal.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

[Hooman Mehr via swift-evolution]

> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> [Proposal: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md
>  
> ]
> 
> Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1.
> 
> One nitpick:
> 
>> This proposal merges the concepts of `class` and `AnyObject`, which now have 
>> the same meaning: they represent an existential for classes. To get rid of 
>> the duplication, we suggest only keeping `AnyObject` around. To reduce 
>> source-breakage to a minimum, `class` could be redefined as `typealias class 
>> = AnyObject` and give a deprecation warning on `class` for the first version 
>> of Swift this proposal is implemented in. Later, `class` could be removed in 
>> a subsequent version of Swift.
> 
> 'class' is a keyword, so we don't get to drop the special parsing no matter 
> what. We can still deprecate it, but I wouldn't bother trying to jam it into 
> a typealias.

Yeah, why bother making 

typealias class = AnyObject

compile?

We should just provide autocorrect to migrate this:

protocol P: class {}

into this:

protocol P: AnyObject {}

and warn if the old syntax is used (while continuing to support it just as it 
works now). We can then remove the parser rules that accept the first form 
(using ‘class’) in Swift 5.

Otherwise strong +1 as it is obviously needed for proper ObjC support.

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

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

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

[Hooman Mehr via swift-evolution]

+1, basically the same response as Matt’s.

> On Feb 28, 2017, at 1:51 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> What is your evaluation of the proposal?
> +1.  Checking things off the list of items on the generics manifesto is 
> always great to see, especially when they allow for improvements in the 
> standard library.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Absolutely.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Very much.
> 
>> 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?
> Quick read, but I have bumped up against this limitation and am really 
> looking forward to seeing it removed.
> 
> ___
> 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] Simplifying case syntax

[Goffredo Marocchi via swift-evolution]

I would think that removing confusion and simplifying + rationalising the 
syntax IS the definition of a breaking change justified :). I do not see how 
Erica's proposal is in any way contrary to the philosophy behind the language 
or is removing anything people really depend on now (in terms of expressive 
ability).

This should be nowhere near as controversial as the removal of pre and post 
increments and C style for loops, quite a slam dunk actually.

Sent from my iPhone

> On 28 Feb 2017, at 23:45, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree. Design 1 seems like an improvement over the status quo. Barring 
> unexpected downsides to this, it's then a question of whether the 
> improvements are large enough to justify a breaking change.
> 
> 
>> On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution 
>>  wrote:
>> I’m happy that someone is trying to fix this small wart in the language. 
>> I’ve always wanted something like Design 1. It makes sense because we are 
>> already used to the pattern matching operator and we finally fix the 
>> inconsistencies between if/guard and switch.
>> 
>>> On 28 Feb 2017, at 20:01, Erica Sadun via swift-evolution 
>>>  wrote:
>>> 
>>> The following draft proposal addresses one matter of substance (eliminating 
>>> edge case errors by adopting at-site conditional binding) and one of style 
>>> (using the pattern match operator consistently). Its discussion was 
>>> deferred from Phase 1 and remains in a fairly early stage. Your feedback 
>>> will help me decide whether this is a proposal I want to keep developing or 
>>> one that I should set aside and focus on other matters. Thank you. -- E
>>> 
>>> The work-in-progress gist is here:  
>>> https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c 
>>> 
>>> Simplifying case syntax
>>> Proposal: TBD
>>> Author: Erica Sadun
>>> Status: TBD
>>> Review manager: TBD
>>> Introduction
>>> 
>>> This proposal re-architects case syntax grammar to reduce potential errors 
>>> and simplify unwrapping enumerations. 
>>> 
>>> Swift-evolution thread: [Pitch] Reimagining guard case/if case
>>> 
>>> Motivation
>>> 
>>> In its current design, Swift case binding suffers from two weaknesses.
>>> 
>>> Mixed external and internal let/var binding may introduce errors from 
>>> uncommon edge cases.
>>> Real-world users may not consider the parallel construction between if 
>>> case/guard case with switchstatements or naturally connect the two layouts.
>>> Internal Case Binding
>>> 
>>> When pattern matching, it's common to bind a variable or constant. It's 
>>> uncommon but legal to use a bound value as an argument. Adopting an "always 
>>> explicit, always within the parentheses" rule adds consistency and safety 
>>> to Swift. 
>>> 
>>> Consider the following enumeration and values:
>>> 
>>> // An enum with one, two, or three associated values
>>> enum Value { case one(T), two(T, T), three(T, T, T) }
>>> 
>>> // An example with two associated values
>>> let example2: Value = .two("a", "b")
>>> 
>>> // A bound symbol
>>> let oldValue = "x"
>>> This code's goal is to conditionally bind newValue and pattern match the 
>>> value stored in the oldValue symbol. The first example succeeds. The second 
>>> example compiles and runs but does not match the coder's intent. Using an 
>>> external letcreates a new oldValue shadow instead of pattern matching 
>>> oldValue's stored value.
>>> 
>>> // Safe
>>> if case .two(let newValue, oldValue) = example2 { 
>>> ... 
>>> }
>>> 
>>> // Syntactically legal but incorrect
>>> if case let .two(newValue, oldValue) = example2 { 
>>> ... 
>>> }
>>> In-parenthesis binding avoids accidental shadowing. It eliminates this 
>>> class of error by adding let and var key words to each use point. This 
>>> creates longer call sites but enumerations rarely contain more than three 
>>> or four associated items.
>>> 
>>> Adopting point-of-use binding enhances clarity and readability. Both if 
>>> case let and if case var (plus case varand case let) may look like single 
>>> compound keywords rather than a combination of two distinct actions to 
>>> developers unfamiliar with this syntax.
>>> 
>>> Pattern Matching with Conditional Binding
>>> 
>>> Swift's guard case and if case align statement design with the switch 
>>> statement, moving the matched value to the right of an equal sign.
>>> 
>>> switch value {
>>> case .enumeration(let embedded): ...
>>> }
>>> 
>>> if case .enumeration(let embedded) = value
>>> The status quo for the = operator is iteratively built up in this fashion:
>>> 
>>> = performs assignment
>>> let x = performs binding
>>> if let x = performs conditional binding on optionals
>>> if case .foo(let x) = performs conditional binding on enumerations and 
>>> applies pattern matching
>>> Using if case/guard case in the absense of conditional binding duplicates 
>>> basic pattern matching with