Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

[Nicholas Maccharoli via swift-evolution]

Nevin,

Yeah I think this works well as an extension on `Comparable`,
 `foo.clamped(to: 1...100)` seems pretty natural.

Why not go one step further and move the versions of min, max that take two
arguments on over to `Comparable` as a protocol extension?

Perhaps something like this?


extension Comparable {

func max(with value: Self) -> Self {
if value > self {
return value
}
return self
}

func min(with value: Self) -> Self {
if value < self {
return value
}
return self
}

func clamped(to range: ClosedRange) -> Self {
let selfUpperMin = range.upperBound.min(with: self)
return range.lowerBound.max(with: selfUpperMin)
}
}


- Nick


On Fri, Mar 10, 2017 at 1:41 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> I’d be on board with an extension of Comparable so you could write
> “16.clamped(to: 0...10)”. Something along the lines of:
>
> extension Comparable {
> func clamped(to range: ClosedRange) -> Self {
> return max(range.lowerBound, min(self, range.upperBound))
> }
> }
>
> Nevin
>
> ___
> 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 ExpressibleByStringInterpolation

[Brent Royal-Gordon via swift-evolution]

> On Mar 9, 2017, at 6:18 PM, Brent Royal-Gordon  wrote:
> 
> ...is the title of a proposal I wrote today. The full proposal is available 
> at:
> 
>   
> 

I've already made a couple of small updates. This URL will reflect them as I 
make them:




-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

[Nevin Brackett-Rozinsky via swift-evolution]

I’d be on board with an extension of Comparable so you could write
“16.clamped(to: 0...10)”. Something along the lines of:

extension Comparable {
func clamped(to range: ClosedRange) -> Self {
return max(range.lowerBound, min(self, range.upperBound))
}
}

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

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

[Nicholas Maccharoli via swift-evolution]

Dave,

Thanks for the feedback!

Yes, there is no explicit need to make `clamp` a global function, and the
extension you proposed would work just fine I think.

`CountableClosedRange` already provides a `clamped(to:)` method but that
does not suit the use case I was thinking of wanting to receive a single
scalar return value rather than a range.

Any chance of dumping `min` and `max` as global functions?
There is already an extension on `Array` for `min` and `max` but that might
carry the overhead of creating an array every time a `min` or `max` is
performed, unless there was some compiler optimization magic that could
come to the rescue.

- Nick

On Fri, Mar 10, 2017 at 10:44 AM, David Sweeris  wrote:

>
> On Mar 9, 2017, at 5:37 PM, Nicholas Maccharoli via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift Evolution,
>
> Having a`clamp` function available in the standard library would
> complement `min` and `max` really well.
>
> I mentioned this before when the discussion for Swift 4 was still in stage
> 1, but now that stage 2 has started I thought it might be worth while to
> bring up again.
>
> Still needs some work, but here is the draft proposal I wrote previously
>
> https://github.com/Nirma/swift-evolution/commit/
> a51c543a76e9a1021996fb4b617311a588e7f397
>
> Basically it boils down to something like this.
>
> public func clamp(value: T, _ lower: T, _ upper: T) -> T {
>   return max(lower, min(value, upper))
> }
>
>
>
> What does the community think?
>
>
> IIRC, we’ve been avoiding top-level functions lately… What about as an
> extension on Range?
>
> extension Range {
> func clamp(_ x: Bound) -> Bound {
> return max(lowerBound, min(x, upperBound))
> }
> }
>
>
> - Dave Sweeris
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

[Brent Royal-Gordon via swift-evolution]

...is the title of a proposal I wrote today. The full proposal is available at:




But the tl;dr is that, if you write this:

"Hello, \(name)!"

Instead of generating this:

.init(stringInterpolation:
.init(stringInterpolationSegment: .init(stringLiteral: "Hello, 
")),
.init(stringInterpolationSegment: name),
.init(stringInterpolationSegment: .init(stringLiteral: "!"))
)

We should generate this:

.init(stringInterpolation:
.init(stringLiteral: "Hello, "),
.init(stringInterpolationSegment: name),
.init(stringLiteral: "!")
)

I actually have an implementation of it, available here:




But I'm literally messing with the constraint generator the very first time I 
modify the compiler, so I'm assuming it'll need some serious code review before 
it actually gets pulled in. (All the regular tests *do* at least pass.)

Despite the word "fix" in the title, this really only does half the job; I 
think we also need to tackle string formatting, at least by adding a mechanism, 
if not by settling on exact APIs. The proposal includes a sketch of my thoughts 
about that as well.

Comments extremely welcome.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Add a `clamp` function to Algorithm.swift

[David Sweeris via swift-evolution]

> On Mar 9, 2017, at 5:37 PM, Nicholas Maccharoli via swift-evolution 
>  wrote:
> 
> Swift Evolution, 
> 
> Having a`clamp` function available in the standard library would complement 
> `min` and `max` really well.
> 
> I mentioned this before when the discussion for Swift 4 was still in stage 1, 
> but now that stage 2 has started I thought it might be worth while to bring 
> up again.
> 
> Still needs some work, but here is the draft proposal I wrote previously
> 
> https://github.com/Nirma/swift-evolution/commit/a51c543a76e9a1021996fb4b617311a588e7f397
>  
> 
> 
> Basically it boils down to something like this.
> 
> public func clamp(value: T, _ lower: T, _ upper: T) -> T {
>   return max(lower, min(value, upper))
> }
> 
> 
> What does the community think?

IIRC, we’ve been avoiding top-level functions lately… What about as an 
extension on Range?
extension Range {
func clamp(_ x: Bound) -> Bound {
return max(lowerBound, min(x, upperBound))
}
}

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

[swift-evolution] Add a `clamp` function to Algorithm.swift

[Nicholas Maccharoli via swift-evolution]

Swift Evolution,

Having a`clamp` function available in the standard library would complement
`min` and `max` really well.

I mentioned this before when the discussion for Swift 4 was still in stage
1, but now that stage 2 has started I thought it might be worth while to
bring up again.

Still needs some work, but here is the draft proposal I wrote previously

https://github.com/Nirma/swift-evolution/commit/a51c543a76e9a1021996fb4b617311a588e7f397

Basically it boils down to something like this.

public func clamp(value: T, _ lower: T, _ upper: T) -> T {
  return max(lower, min(value, upper))
}



What does the community think?

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

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Rick Ballard via swift-evolution]

> Proposal link:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md

> On Mar 9, 2017, at 3:02 PM, Karl Wagner  wrote:
> 
>> On 9 Mar 2017, at 23:48, Karl Wagner > > wrote:
>> 
>>> On 9 Mar 2017, at 23:32, Rick Ballard >> > wrote:
>>> 
 On Mar 9, 2017, at 2:30 PM, Karl Wagner > wrote:
>>> 
> * Is the problem being addressed significant enough to warrant a change 
> to the Swift Package Manager?
 
 Not really. The package manifest API has lots of serious deficiencies and 
 this proposal shuffles a couple of names around. Not sure it’s really 
 worth the hassle, to be honest. It’s certainly very far from a “redesign”!
>>> 
>>> 
>>> Would you mind expanding on the other deficiencies that you see in this API?
>> 
>> I think they’re rather well-known:
>> 
>> - No support for resources; means no test resources (!), framework or 
>> application bundles.
>> - System package API is confusing, doesn’t account for OSX system libraries 
>> (“.tbd” files you see in Xcode’s “Link Libraries” panel).
>> - Source trees are exclude-only with no ability to selectively *include* 
>> other trees.
>> - Every package must have an independent source control repository. Even if 
>> it’s just redirecting to a system library (of which you can only sometimes 
>> really control the version).
>> - (Related) It would be nice if we could refer to independent modules within 
>> the same repository, who have their own Package.swift detailing their 
>> dependencies (like a “sub-package”). This can be helpful when developing 
>> modular applications or, as mentioned, when importing some external 
>> libraries from the system or another package manager.
>> 
>> - Package manager doesn’t resolve dependencies between files in the same 
>> module. You have to resolve it yourself and name the files alphabetically 
>> (this may be a bug rather than a missing feature, but I couldn’t find 
>> anything in the source which sorted the compiler inputs...)
> 
> I mean — not to be too negative. The package manager is very cool and I’m 
> looking forward to the day when it works for more projects.
> 
> My point was that there are lots of large gaps in the current model, and 
> personally I’d rather we rolled those all together in a “Package.swift v2” 
> rather than making frequent source-breaking changes for cosmetic 
> enhancements. Anything which is additive is fine, but frequent renaming gets 
> annoying.


The point of this proposal is to do a one-time clean-up and standardization of 
existing API. We indeed have a lot of new API we also need to add, including 
things you mention above, but those are intentionally out of scope for this 
proposal; instead, each of those additions should have its own proposal and 
discussion. Getting this clean-up out of the way now of course means that those 
new APIs will have a clear set of API design standards to follow when they're 
added. We are not expecting to rename these APIs again in the future, so this 
won't be a "frequent" change.

So setting aside the things that we should add in the future, if you don't 
think it's a good idea to clean up the existing API, that would be feedback we 
can discuss here. It sounds like you're saying that the hassle of existing 
packages needing to revise their API use when they adopt Swift 4 is not worth 
the benefits that this proposal brings – consistency, clarity, flexibility, 
extensibility, language guidelines compliance, etc. I respectfully disagree, 
but if you have some more details on why this is going to cause a problem to 
do, or why living with the existing API's problems moving forward isn't a 
problem, I'd be happy to discuss that. More specifically, if there are changes 
to the *existing* API (which don't add significant new functionality) that this 
proposal does make which you disagree with, or which it doesn't make that you 
think should happen, this would be the time to discuss that.

Thanks,

- Rick

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

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Karl Wagner via swift-evolution]

> On 9 Mar 2017, at 23:48, Karl Wagner  wrote:
> 
> 
>> On 9 Mar 2017, at 23:32, Rick Ballard > > wrote:
>> 
>> > Proposal link:
>> >>  
>> >> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
>> >>  
>> >> 
>> 
>>> On Mar 9, 2017, at 2:30 PM, Karl Wagner >> > wrote:
>> 
 * Is the problem being addressed significant enough to warrant a change to 
 the Swift Package Manager?
>>> 
>>> Not really. The package manifest API has lots of serious deficiencies and 
>>> this proposal shuffles a couple of names around. Not sure it’s really worth 
>>> the hassle, to be honest. It’s certainly very far from a “redesign”!
>> 
>> 
>> Hi Karl,
>> 
>> Would you mind expanding on the other deficiencies that you see in this API?
>> 
>> Thanks,
>> 
>>  - Rick
>> 
> 
> I think they’re rather well-known:
> 
> - No support for resources; means no test resources (!), framework or 
> application bundles.
> - System package API is confusing, doesn’t account for OSX system libraries 
> (“.tbd” files you see in Xcode’s “Link Libraries” panel).
> - Source trees are exclude-only with no ability to selectively *include* 
> other trees.
> - Every package must have an independent source control repository. Even if 
> it’s just redirecting to a system library (of which you can only sometimes 
> really control the version).
> - (Related) It would be nice if we could refer to independent modules within 
> the same repository, who have their own Package.swift detailing their 
> dependencies (like a “sub-package”). This can be helpful when developing 
> modular applications or, as mentioned, when importing some external libraries 
> from the system or another package manager.
> 
> - Package manager doesn’t resolve dependencies between files in the same 
> module. You have to resolve it yourself and name the files alphabetically 
> (this may be a bug rather than a missing feature, but I couldn’t find 
> anything in the source which sorted the compiler inputs...)

I mean — not to be too negative. The package manager is very cool and I’m 
looking forward to the day when it works for more projects.

My point was that there are lots of large gaps in the current model, and 
personally I’d rather we rolled those all together in a “Package.swift v2” 
rather than making frequent source-breaking changes for cosmetic enhancements. 
Anything which is additive is fine, but frequent renaming gets annoying.

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

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

[David Sweeris via swift-evolution]

> On Mar 9, 2017, at 04:40, Ross O'Brien via swift-evolution 
>  wrote:
> 
> I could see a purpose for identifiers which started numbers but weren't 
> entirely numerical.
> e.g.
> enum Dimensions { case `2D`, `3D` }
> enum DiceRoll { case d6, `2d6` }
> func roll(dice: DiceRoll) -> Int { ... }
> roll(.`2d6`)
> 
> I'm not sure I see one for identifiers which are entirely numerical.

That's certainly a much easier sell... How does "_" fit into this? I know 
`123_456` is a valid integer literal and that `_1` is a valid identifier. I 
don't know if `_1` is a valid integer literal.

I'd like to support purely numeric identifiers, but I can't think of a way 
around the ambiguity of `3.0`. Maybe only allow it if the enclosing type isn't 
ExpressibleByIntegerLiteral? It feels more than a bit odd, though, to have a 
property name's validity depend on whether or not it's in a 
ExpressibleByIntegerLiteral type.

- Dave Sweeris

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

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Karl Wagner via swift-evolution]

> On 9 Mar 2017, at 23:32, Rick Ballard  wrote:
> 
> > Proposal link:
> >>  
> >> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
> >>  
> >> 
> 
>> On Mar 9, 2017, at 2:30 PM, Karl Wagner > > wrote:
> 
>>> * Is the problem being addressed significant enough to warrant a change to 
>>> the Swift Package Manager?
>> 
>> Not really. The package manifest API has lots of serious deficiencies and 
>> this proposal shuffles a couple of names around. Not sure it’s really worth 
>> the hassle, to be honest. It’s certainly very far from a “redesign”!
> 
> 
> Hi Karl,
> 
> Would you mind expanding on the other deficiencies that you see in this API?
> 
> Thanks,
> 
>   - Rick
> 

I think they’re rather well-known:

- No support for resources; means no test resources (!), framework or 
application bundles.
- System package API is confusing, doesn’t account for OSX system libraries 
(“.tbd” files you see in Xcode’s “Link Libraries” panel).
- Source trees are exclude-only with no ability to selectively *include* other 
trees.
- Every package must have an independent source control repository. Even if 
it’s just redirecting to a system library (of which you can only sometimes 
really control the version).
- (Related) It would be nice if we could refer to independent modules within 
the same repository, who have their own Package.swift detailing their 
dependencies (like a “sub-package”). This can be helpful when developing 
modular applications or, as mentioned, when importing some external libraries 
from the system or another package manager.

- Package manager doesn’t resolve dependencies between files in the same 
module. You have to resolve it yourself and name the files alphabetically (this 
may be a bug rather than a missing feature, but I couldn’t find anything in the 
source which sorted the compiler inputs...)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Daniel Duan via swift-evolution]

Here’s an updated version with hopefully the correct content. The “overloaded” 
case feature has been removed and is discussed in the "alternatives considered" 
section.


# Normalize Enum Case Representation

* Proposal: [SE-0155][]
* Authors: [Daniel Duan][], [Joe Groff][]
* Review Manager: [John McCall][]
* Status: **Awaiting review**
* Previous Revision: [1][Revision 1]

## Introduction

In Swift 3, associated values of an enum case are represented by a tuple. This
implementation causes inconsistencies in case declaration, construction and
pattern matching in several places.

Enums, therefore, can be made more "regular" when we replace tuple as the
representation of associated case values. This proposal aims to define the
effect of doings so on various parts of the language.

Swift-evolution thread: [Normalize Enum Case Representation (rev. 2)][]

## Motivation

When user declares a case for an enum, a function which constructs the
corresponding case value is declared. We'll refer to such functions as _case
constructors_ in this proposal.

```swift
enum Expr {
// this case declares the case constructor `Expr.elet(_:_:)`
indirect case elet(locals: [(String, Expr)], body: Expr)
}

// f's signature is f(_: _), type is ([(String, Expr)], Expr) -> Expr
let f = Expr.elet

// `f` is just a function
f([], someExpr) // construct a `Expr.elet`
```

There are many surprising aspects of enum constructors, however:

1. After [SE-0111][], Swift function's fully qualified name consists of its base
   name and all of its argument labels. User can use the full name of the
   function at use site. In the example above, `locals` and `body` are currently
   not part of the case constructors name, therefore the expected syntax is
   invalid.

   ```swift
   func f(x: Int, y: Int) {}
   f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
   Expr.elet(locals: body:)([], someExpr) // this doesn't work in Swift 3
   ```
2. Case constructors cannot include a default value for each parameter. This
   is yet another feature available to functions.

As previous mentioned, these are symptoms of associated values being a tuple
instead of having its own distinct semantics. This problem manifests more in
Swift 3's pattern matching:

1. A pattern with a single value would match and result in a tuple:

```swift
// this works for reasons most user probably don't expect!
if case .elet(let wat) = anExpr {
eval(wat.body)
}
```

2. Labels in patterns are not enforced:

```swift
// note: there's no label in the first sub-pattern
if case .elet(let p, let body: q) = anExpr {
// code
}
```

These extra rules makes pattern matching difficult to teach and to expand to
other types.

## Proposed Solution

We'll add first class syntax (which largely resemble the syntax in Swift 3) for
declaring associated values with labels. Tuple will no longer be used to
represent the aggregate of associated values for an enum case. This means
pattern matching for enum cases needs its own syntax as well (as opposed to
piggybacking on tuple patterns, which remains in the language for tuples.).

## Detailed Design

### Compound Names For Enum Constructors

Associated values' labels should be part of the enum case's constructor name.
When constructing an enum value with the case name, label names must either be
supplied in the argument list it self, or as part of the full name.

```swift
Expr.elet(locals: [], body: anExpr) // Okay, the Swift 3 way.
Expr.elet(locals: body:)([], anExpr) // Okay, equivalent to the previous line.
Expr.elet(locals: body:)(locals: 0, body: 0) // This would be an error, however.
```

Note that since the labels aren't part of a tuple, they no longer participate in
type checking, behaving consistently with functions.

```swift
let f = Expr.elet // f has type ([(String, Expr)], Expr) -> Expr
f([], anExpr) // Okay!
f(locals: [], body: anExpr) // Won't compile.
```

Enum cases should have distinct *full* names. Therefore, shared base name will
be allowed:

```swift
enum SyntaxTree {
case type(variables: [TypeVariable])
case type(instantiated: [Type])
}
```

Using only the base name in pattern matching for the previous example would be
ambiguous and result in an compile error. In this case, the full name must be
supplied to disambiguate.

```swift
case .type // error: ambiguous
case .type(variables: let variables) // Okay
```

### Default Parameter Values For Enum Constructors

From a user's point view, declaring an enum case should remain the same as Swift
3 except now it's possible to add `= expression` after the type of an
associated value to convey a default value for that field.

```swift
enum Animation {
case fadeIn(duration: TimeInterval = 0.3) // Okay!
}
let anim = Animation.fadeIn() // Great!
```

Updated syntax:

```ebnf
union-style-enum-case = enum-case-name [enum-case-associated-value-clause];
enum-case-associated-value-clause = "(" ")"

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Rick Ballard via swift-evolution]

> Proposal link:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
>>  
>> 

> On Mar 9, 2017, at 2:30 PM, Karl Wagner  wrote:

>> * Is the problem being addressed significant enough to warrant a change to 
>> the Swift Package Manager?
> 
> Not really. The package manifest API has lots of serious deficiencies and 
> this proposal shuffles a couple of names around. Not sure it’s really worth 
> the hassle, to be honest. It’s certainly very far from a “redesign”!


Hi Karl,

Would you mind expanding on the other deficiencies that you see in this API?

Thanks,

- Rick

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

Re: [swift-evolution] [Review] SE-0158 Package Manager Manifest API Redesign

[Karl Wagner via swift-evolution]

> On 7 Mar 2017, at 21:53, Rick Ballard via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0158 Package Manager Manifest API Redesign" begins now and 
> runs through March 13, 2017. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All Swift 
> Package Manager reviews should be sent to the swift-evolution and 
> swift-build-dev mailing lists at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
>   https://lists.swift.org/mailman/listinfo/swift-build-dev
> 
> 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/0158-package-manager-manifest-api-redesign.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?

+0. Meh.

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

Not really. The package manifest API has lots of serious deficiencies and this 
proposal shuffles a couple of names around. Not sure it’s really worth the 
hassle, to be honest. It’s certainly very far from a “redesign”!

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

Sure, I suppose

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

I’ve used other package managers. Again, it’s really neither here nor there.

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

Read the prior discussion, and the proposal again.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> - Rick Ballard
> 
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

[David Sweeris via swift-evolution]

> On Mar 8, 2017, at 22:34, Ankit Aggarwal  wrote:
> 
>  
>> +1, although I don’t know why we're supporting this:
>> // 1.5.8 ..< 2.0.0
>> .package(url: "/SwiftyJSON", from: "1.5.8"),
>> when, at least as far as I can tell, this:
>> // 1.5.8 ..< 2.0.0
>> .package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8")),
>> does the same thing, and the spelling is, at least to me, clearer as well. 
>> Dunno, maybe the “from” version is a term of art that I’m just not familiar 
>> with.
> 
> Hi David,
> 
> Thank you for the review. 
> 
> It is true that `from` and `.uptoNextMajor` are exactly same. We think that 
> the most widely used requirement will be `.uptoNextMajor`, so we wanted to 
> provide a shorthand for it.

Ok, I just wanted to make sure having both spellings was intentional. I've been 
trying to think of a shorthand that's clearer, but haven't really come up with 
anything.

Seems like we're fighting English's grammar... With the non-shorthand spelling, 
the "normal" way to write that would have the version first, followed by the 
modifier. Adapted to pseudo-code, it would be `1.5.8.uptoNextMajor()`, which 
Swift currently can't support. And "from" is typically followed by "to" or 
"through", which makes the shorthand kinda odd as well. 

Sorry, I should've noticed this during the discussion thread. Since this the 
review thread, though, I want to make it clear that I'm still +1, and think 
this spelling issue (to the extent that it is one) isn't worth derailing the 
proposal.

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

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Daniel Duan via swift-evolution]

cc’ing Xiaodi
> On Mar 9, 2017, at 1:53 PM, Joe Groff  wrote:
> 
> 
>> On Mar 8, 2017, at 7:09 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> Hi everyone,
>> 
>> Here’s revision 2 of SE-0155. I’d love some feedback before going into 
>> re-review.
>> 
>> Note the “anonymous case” feature is not in this proposal. I found the 
>> motivation section difficult to write when it’s included. I’ve drafted a 
>> separate proposal that adds it.
>> 
>> Rendered version: 
>> https://github.com/dduan/swift-evolution/blob/SE0155-rev2/proposals/0155-normalize-enum-case-representation.md
>>  
>> 
> 
> You appear to have pasted a different version below from what's rendered at 
> that link.
> 
> Some comments:
> 
> - Overloading seems like unnecessarily distracting scope creep. I would leave 
> it out.

Great, this certainly solves a lot of unresolved problems being discussed here! 
:P

> - Having `case leaf()` have type Tree is IMO more surprising than making it 
> equivalent to `case leaf`. It should either behave as if it were a method, or 
> be banned outright. We don't need two ways to spell the same thing.

Sounds good!

> 
> -Joe
> 

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

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Joe Groff via swift-evolution]

> On Mar 9, 2017, at 5:59 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I have argued repeatedly that enum cases play two distinct roles (and 
> sometimes a third in the future).  We need to embrace all of these roles.  
> This proposal primarily normalizes the role of case-as-factory-method.  
> 
> Pattern matching is a second role enum cases play.  We already have syntax 
> for patterns that match based on type.  I see no reason we should introduce 
> new matching syntax to disambiguate overloaded cases.  The existing patterns 
> work well for this purpose.  Matching should be considered a role played by 
> enum cases that is completely orthogonal to their role as a factory method.

Matching and construction are closely related and designed to mimic each other. 
They aren't completely orthogonal.

-Joe

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

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Joe Groff via swift-evolution]

> On Mar 8, 2017, at 7:09 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> Here’s revision 2 of SE-0155. I’d love some feedback before going into 
> re-review.
> 
> Note the “anonymous case” feature is not in this proposal. I found the 
> motivation section difficult to write when it’s included. I’ve drafted a 
> separate proposal that adds it.
> 
> Rendered version: 
> https://github.com/dduan/swift-evolution/blob/SE0155-rev2/proposals/0155-normalize-enum-case-representation.md
>  
> 

You appear to have pasted a different version below from what's rendered at 
that link.

Some comments:

- Overloading seems like unnecessarily distracting scope creep. I would leave 
it out.

- Having `case leaf()` have type Tree is IMO more surprising than making it 
equivalent to `case leaf`. It should either behave as if it were a method, or 
be banned outright. We don't need two ways to spell the same thing.

-Joe

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

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Joe Groff via swift-evolution]

> On Mar 9, 2017, at 11:48 AM, Daniel Duan  wrote:
> 
>> 
>> On Mar 9, 2017, at 12:31 AM, Xiaodi Wu > > wrote:
>> 
>> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan > > wrote:
>> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to 
>> incorporate some of the responses into the proposal.
>> 
>> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu > > wrote:
>> 
>>> The rendered version differs from the text appended to your message. I'll 
>>> assume the more fully fleshed out version is what you intend to submit. 
>>> Three comments/questions:
>>> 
>>> Enum Case "Overloading"
>>> 
>>> An enum may contain cases with the same full name but with associated 
>>> values of different types. For example:
>>> 
>>> enum Expr {
>>> case literal(Bool)
>>> case literal(Int)
>>> }
>>> The above cases have overloaded constructors, which follow the same rules 
>>> as functions at call site for disambiguation:
>>> 
>>> // It's clear which case is being constructed in the following.
>>> let aBool: Expr = .literal(false)
>>> let anInt: Expr = .literal(42)
>>> User must specify an as expression in sub-patterns in pattern matching, in 
>>> order to match with such cases:
>>> 
>>> case .literal(let value) // this is ambiguous
>>> case .literal(let value as Bool) // matches `case literal(Bool)`
>>> 
>>> Comment/question 1: Here, why aren't you proposing to allow `case 
>>> .literal(let value: Bool)`? For one, it would seem to be more consistent.
>> 
>> The example in proposal doesn't include any labels. Are you suggesting two 
>> colons for sub-patterns with labels? Like `case .literal(value: let value: 
>> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.
>> 
>> That does look jarring. But hmm.
>>  
>>> Second, since we still have some use cases where there's Obj-C bridging 
>>> magic with `as`, using `as` in this way may run into ambiguity issues if 
>>> (for example) you have two cases, one with associated value of type 
>>> `String` and the other of type `NSString`.
>> 
>> Either this should be rejected at declaration, or we need a way to accept a 
>> "pre-magic" resolution at pattern matching, when this scenarios is at hand.
>> 
>> Or we align pattern matching to function syntax and have such cases 
>> disambiguated in that way (see below).
>>  
>> I'm on the phone so I can't verify. Wouldn't function overloading face a 
>> similar problem?
>> 
>>> Also, since enum cases are to be like functions, I assume that the more 
>>> verbose `as` version would work for free: `case .literal(let value) as 
>>> (Bool) -> Expr`?
>>> 
>> 
>> This is not being proposed. When a user sees/authors a case, their 
>> expectation for the declared case constructor should resemble that of a 
>> function. Pattern matching was considered separately since it's not 
>> relatable syntactically.
>> 
>> This requires justification. If enum cases are to be like functions, then 
>> the logical expectation is that pattern matching should work in that way 
>> too. I see no rationale to undergird your claim that pattern matching is 
>> "not relatable syntactically." Allowing `case .literal(let value) as (Bool) 
>> -> Expr` would solve the issue above, as well as provide more flexibility 
>> with the issues below.
> 
> I have concerns about the verbosity this syntax introduces. Example:
> 
> enum A { case v(Int) }
> enum B { case v(A); case v(Int) }
> 
> To disambiguate a value of type B, it would be
> 
> case .v(A.v(let xValue)) as ((Int -> A) -> B)
> 
> This scales poorly for cases with deeper recursions and/or more associated 
> values.
> 
> Disambiguate at the sub-pattern level doesn’t have this scalability problem.

This also is not the right meaning of `as`. `as` coerces the subpattern type, 
and a `.v(...)` pattern has type B. This coercion makes no sense.

Personally I think that overloading is unnecessary scope creep and should be 
left out of the proposal.

> —
> 
> We’ve encountered a bigger question that it initial seems. Let’s zoom out.
> 
> There are 2 popular kinds of patterns for value deconstruction in PLs: 
> patterns for trees and sequences. The former deconstructs value who’s 
> prominently recursive: enum, struct, tuple; the latter deals with list-like 
> (grows in 1 direction indefinitely) things. We are now investigating the 
> syntax that can potentially be used for all tree patterns. Whereas the 
> “shape” alone isn’t enough information, user must use the type to supplement 
> the pattern for a successful match. If we introduce patterns for structs in 
> the future, whatever we came up here for type disambiguation should work 
> there.
>>>  
>>> Alternative
>>>  Payload-less Case 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 9, 2017, at 10:43 AM, Ricardo Parada  wrote:
> 
> In other languages I normally have a method with a variable number of 
> arguments and another one taking an array. Then one typically ends up calling 
> the other. 
> 
> If we had implicit splatting I imagine it would reduce such methods to only 
> one. 
> 
> However if implicit splatting were to cause problems I think it would be nice 
> to do it explicitly as follows:
> 
> foo(args as Argument…)

That would depend on Joe Groff’s proposal “Replacing `as` for bridging coercion"
[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from 
`as`/`is`/`as?` casts



> 
> 
> On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution 
> > wrote:
> 
>> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de > 
>>> wrote:
>>> 
 These is very unfortunate as a solution for “spreading” a collection or 
 tuple so that It can be applied to function taking a variadic.
 It makes sense on the declaration site but not on the call site. 
 
 someFunc(@nonVariadic [1])  
 someFunc(@variadic [1]) 
 
 There is nothing special about variadic/ spreading that would warrant an 
 attribute. 
 
 I think using attributes is not different than using a keyword like c# 
 uses. 
 http://stackoverflow.com/questions/7580277/why-use-the-params-keyword 
 
 
 Do we really want to tag every array/tuple with a @variadic or 
 @nonVariadic tag when packing and unpacking parameters?
 
 variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
 most languages. 
>>> 
>>> I have the impression there is a misunderstanding about the proposal:
>>> It would not only make the variadics-syntax superflous, but also the whole 
>>> splatting-magic.
>>> There would only be functions that accept arrays, and you could freely 
>>> choose to feed them a comma-seperated list instead.
>>> The attribute would be written in the function declaration only — and we 
>>> could even decide that it isn't needed at all, and simply accept lists 
>>> wherever an array is expected.
>> 
>> Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
>> would reintroduce it for Array like constructs. 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
>>  
>> 
>> 
>> I am in favor in explicit splat behavior but I don’t see it happening 
>> anytime soon. Its tagged as low priority.  
>> 
>>  
>> ___
>> 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] Normalize Enum Case Representation (rev. 2)

[Daniel Duan via swift-evolution]

> On Mar 9, 2017, at 12:31 AM, Xiaodi Wu  wrote:
> 
> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan  > wrote:
> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to 
> incorporate some of the responses into the proposal.
> 
> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu  > wrote:
> 
>> The rendered version differs from the text appended to your message. I'll 
>> assume the more fully fleshed out version is what you intend to submit. 
>> Three comments/questions:
>> 
>> Enum Case "Overloading"
>> 
>> An enum may contain cases with the same full name but with associated values 
>> of different types. For example:
>> 
>> enum Expr {
>> case literal(Bool)
>> case literal(Int)
>> }
>> The above cases have overloaded constructors, which follow the same rules as 
>> functions at call site for disambiguation:
>> 
>> // It's clear which case is being constructed in the following.
>> let aBool: Expr = .literal(false)
>> let anInt: Expr = .literal(42)
>> User must specify an as expression in sub-patterns in pattern matching, in 
>> order to match with such cases:
>> 
>> case .literal(let value) // this is ambiguous
>> case .literal(let value as Bool) // matches `case literal(Bool)`
>> 
>> Comment/question 1: Here, why aren't you proposing to allow `case 
>> .literal(let value: Bool)`? For one, it would seem to be more consistent.
> 
> The example in proposal doesn't include any labels. Are you suggesting two 
> colons for sub-patterns with labels? Like `case .literal(value: let value: 
> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.
> 
> That does look jarring. But hmm.
>  
>> Second, since we still have some use cases where there's Obj-C bridging 
>> magic with `as`, using `as` in this way may run into ambiguity issues if 
>> (for example) you have two cases, one with associated value of type `String` 
>> and the other of type `NSString`.
> 
> Either this should be rejected at declaration, or we need a way to accept a 
> "pre-magic" resolution at pattern matching, when this scenarios is at hand.
> 
> Or we align pattern matching to function syntax and have such cases 
> disambiguated in that way (see below).
>  
> I'm on the phone so I can't verify. Wouldn't function overloading face a 
> similar problem?
> 
>> Also, since enum cases are to be like functions, I assume that the more 
>> verbose `as` version would work for free: `case .literal(let value) as 
>> (Bool) -> Expr`?
>> 
> 
> This is not being proposed. When a user sees/authors a case, their 
> expectation for the declared case constructor should resemble that of a 
> function. Pattern matching was considered separately since it's not relatable 
> syntactically.
> 
> This requires justification. If enum cases are to be like functions, then the 
> logical expectation is that pattern matching should work in that way too. I 
> see no rationale to undergird your claim that pattern matching is "not 
> relatable syntactically." Allowing `case .literal(let value) as (Bool) -> 
> Expr` would solve the issue above, as well as provide more flexibility with 
> the issues below.

I have concerns about the verbosity this syntax introduces. Example:

enum A { case v(Int) }
enum B { case v(A); case v(Int) }

To disambiguate a value of type B, it would be

case .v(A.v(let xValue)) as ((Int -> A) -> B)

This scales poorly for cases with deeper recursions and/or more associated 
values.

Disambiguate at the sub-pattern level doesn’t have this scalability problem.

—

We’ve encountered a bigger question that it initial seems. Let’s zoom out.

There are 2 popular kinds of patterns for value deconstruction in PLs: patterns 
for trees and sequences. The former deconstructs value who’s prominently 
recursive: enum, struct, tuple; the latter deals with list-like (grows in 1 
direction indefinitely) things. We are now investigating the syntax that can 
potentially be used for all tree patterns. Whereas the “shape” alone isn’t 
enough information, user must use the type to supplement the pattern for a 
successful match. If we introduce patterns for structs in the future, whatever 
we came up here for type disambiguation should work there.
>>  
>> Alternative
>>  Payload-less Case Declaration
>> 
>> In Swift 3, the following syntax is valid:
>> 
>> enum Tree {
>> case leaf() // the type of this constructor is confusing!
>> }
>> Tree.leaf has a very unexpected type to most Swift users: (()) -> Tree
>> 
>> We propose this syntax declare the "bare" case instead. So it's going to be 
>> the equivalent of
>> 
>> enum Tree {
>> case leaf // `()` is optional and does the same thing.
>> }
>> 
>> 
>> Comment/question 2: First, if associated values are not to be modeled as 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Ricardo Parada via swift-evolution]

In other languages I normally have a method with a variable number of arguments 
and another one taking an array. Then one typically ends up calling the other. 

If we had implicit splatting I imagine it would reduce such methods to only 
one. 

However if implicit splatting were to cause problems I think it would be nice 
to do it explicitly as follows:

foo(args as Argument...)


> On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote:
>>> 
>>> These is very unfortunate as a solution for “spreading” a collection or 
>>> tuple so that It can be applied to function taking a variadic.
>>> It makes sense on the declaration site but not on the call site. 
>>> 
>>> someFunc(@nonVariadic [1])  
>>> someFunc(@variadic [1]) 
>>> 
>>> There is nothing special about variadic/ spreading that would warrant an 
>>> attribute. 
>>> 
>>> I think using attributes is not different than using a keyword like c# 
>>> uses. 
>>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword
>>> 
>>> Do we really want to tag every array/tuple with a @variadic or @nonVariadic 
>>> tag when packing and unpacking parameters?
>>> 
>>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
>>> most languages. 
>> 
>> I have the impression there is a misunderstanding about the proposal:
>> It would not only make the variadics-syntax superflous, but also the whole 
>> splatting-magic.
>> There would only be functions that accept arrays, and you could freely 
>> choose to feed them a comma-seperated list instead.
>> The attribute would be written in the function declaration only — and we 
>> could even decide that it isn't needed at all, and simply accept lists 
>> wherever an array is expected.
> 
> Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
> would reintroduce it for Array like constructs. 
> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
> 
> I am in favor in explicit splat behavior but I don’t see it happening anytime 
> soon. Its tagged as low priority.  
> 
>  
> ___
> 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-build-dev] [Draft] Package Manager Manifest API Redesign

[Karl Wagner via swift-evolution]

> On 28 Feb 2017, at 17:05, Daniel Dunbar via swift-evolution 
>  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

The pkgConfig functionality could be generalised, though. For example, OSX’s 
system modulemap (found at: 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/module.modulemap)
 does not provide any linker information. Instead, you need to manually include 
those weird “.tbd” files in Xcode's “Link Libraries” panel — try a package with 
"import Darwin.ncurses” and you won’t be able to link.

Either OSX’s system modulemap gets better (and linux’s too, I suppose), or we 
need the ability to include that linker information in the package manifest for 
more formats than just pkg-config.

- Karl

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

Re: [swift-evolution] Swift 4: Support for static libs / modular development.

[Jacek Suliga via swift-evolution]

I'd like to add a +1 for this request/discussion starter.
We're on the same boat, with 70+ dynamic libraries, facing the same
challenges as Raphael mentioned.

Jacek Suliga | Flagship Infra

On Fri, Feb 17, 2017 at 10:02 AM, Raphael Sebbe via swift-evolution <
swift-evolution@swift.org> wrote:

> Sure, thank you. If SwiftPM gets a working integration in Xcode 9, that
> could do it.
>
> Raphael
>
> On Fri, Feb 17, 2017 at 1:50 PM Ole Begemann  wrote:
>
>>
>> > On 17 Feb 2017, at 10:28, Raphael Sebbe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I'm not fully aware of the state of discussion, so sorry if it is
>> already being addressed. I wanted to bring some feedback and awareness
>> about the need of a supported way to build app components as *static
>> libraries* in Swift.
>>
>> Part of the recently accepted (for Swift 4) SE-0146 "Package Manager
>> Product Definitions" [1] is support for static library products in the
>> Swift Package Manager.
>>
>> SwiftPM is not Xcode, of course. I just thought I'd mention it.
>>
>> [1]: https://github.com/apple/swift-evolution/blob/master/
>> proposals/0146-package-manager-product-definitions.md
>>
>>
> ___
> 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] Remove support for final in protocol extensions

[T.J. Usiyan via swift-evolution]

+1 for the fix. Solid and straightforward.

On Thu, Mar 9, 2017 at 9:32 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> There has been a lot of discussion around this design decision.
> Personally, I’m with you: this should be allowed. Protocol extensions
> should be defaults, nothing more.
>
> The rationale mentioned in Swift Evolution for discouraging this behaviour
> tends to be that if you conform to the protocol, you should conform and
> adhere to all its extensions as well, and that not doing so in the same way
> will be inconsistent.
>
> I personally think this comes to the Type-first vs Protocol-first approach
> and I think instances of types should have the final say in the behaviour
> of the operation. While this would perform slightly worse, and could
> potentially be unsafe, I think it is consistent with the fact that not all
> implementers of a protocol behave exactly the same; indeed, if they did,
> we’d only have one type per protocol, in which case, what is the point of a
> protocol at all? Just do it with types.
>
> I love POP and protocol extensions but I’m tempered by the fact that not
> all types implement protocols in the same ways, and we can’t predict ahead
> of time where those differences will be needed.
>
>
> On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My question is why cannot the Base type override the default
> implementation? I might want to override it, by calling the default
> implementation and modifying the result for my needs.
>
> Something like that:
>
> protocol P {
> func foo() -> Int
> }
>
> extension P {
> func foo() -> Int {
> return 42
> }
> }
>
> class Base : P {
> override func foo() -> {
>
> return default.foo() * 100
> }
> }
>
> The example is kept simple.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>
>
> Sent from my iPad
>
> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think the fact that the type checker permits ‘final’ to appear inside
> protocol extensions is an oversight and this probably does not even warrant
> a proposal. I don’t think allowing this was ever part of the conceptual
> model of protocol extensions at any point in time (if you recall they were
> introduced ‘recently’, in Swift 2). If someone put together a PR which
> makes ‘final’ in protocol extensions an error in Swift 4 mode (and a
> warning in 3), I would merge it.
>
> FWIW that there is one restriction around the direct dispatch here we want
> to lift, but it’s not related to this proposal.
>
> If you have a base class conforming to a protocol using default
> requirements, eg
>
>   protocol Proto { func f() }
>   extension Proto { func f() { } }
>
>   class Base : Proto {}
>
> Currently the witness table for Base : Proto directly references the
> extension method Proto.f.
>
> We want to allow this, at least inside the module:
>
> class Derived {
>   override func f() {} // does not work currently
> }
>
> This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’,
> pointing at the extension method. The conformance will dispatch through the
> vtable instead of directly calling the extension method.
>
>
> Would this allow the override to call `Proto.f` through super?
>
>
> Slava
>
> On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
> this is in scope for Swift 4 since it impacts source compatibility. It's
> not a very exciting proposal, but I think it will help make Swift a little
> more consistent.
>
> https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7
> https://bugs.swift.org/browse/SR-1762
>
> Thanks
>
> Brian
> Introduction
>
> This proposal suggests removing support for the final keyword when
> declaring a function in a protocol extension. The presence of the final 
> keyword
> does not currently generate an error message, and it does not actually
> modify the dispatch behavior in any way.
>
> 
> Motivation
>
> In the original protocol model of Swift, a developer could use the final 
> keyword
> when declaring a function in a protocol extension to ensure the function
> could not be overridden. This keyword has no use in Swift's current
> protocol model, since functions in protocol extensions can not be
> overridden and will always use direct dispatch.
>
> Detailed
> design
>
> The compiler should generate an error or warning when the final keyword
> is used on a function declaration inside of a protocol extension. This is
> consistent with the use of final in structs and 

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

[Rod Brown via swift-evolution]

There has been a lot of discussion around this design decision. Personally, I’m 
with you: this should be allowed. Protocol extensions should be defaults, 
nothing more.

The rationale mentioned in Swift Evolution for discouraging this behaviour 
tends to be that if you conform to the protocol, you should conform and adhere 
to all its extensions as well, and that not doing so in the same way will be 
inconsistent.

I personally think this comes to the Type-first vs Protocol-first approach and 
I think instances of types should have the final say in the behaviour of the 
operation. While this would perform slightly worse, and could potentially be 
unsafe, I think it is consistent with the fact that not all implementers of a 
protocol behave exactly the same; indeed, if they did, we’d only have one type 
per protocol, in which case, what is the point of a protocol at all? Just do it 
with types.

I love POP and protocol extensions but I’m tempered by the fact that not all 
types implement protocols in the same ways, and we can’t predict ahead of time 
where those differences will be needed.


> On 10 Mar 2017, at 12:48 am, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> My question is why cannot the Base type override the default implementation? 
> I might want to override it, by calling the default implementation and 
> modifying the result for my needs.
> 
> Something like that:
> 
> protocol P {
> func foo() -> Int
> }
> 
> extension P {
> func foo() -> Int {
> return 42
> }
> }
> 
> class Base : P {
> override func foo() -> {
>  
> return default.foo() * 100
> }
> }
> The example is kept simple.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. März 2017 um 14:37:08, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>> 
>> Sent from my iPad
>> 
>> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>>> I think the fact that the type checker permits ‘final’ to appear inside 
>>> protocol extensions is an oversight and this probably does not even warrant 
>>> a proposal. I don’t think allowing this was ever part of the conceptual 
>>> model of protocol extensions at any point in time (if you recall they were 
>>> introduced ‘recently’, in Swift 2). If someone put together a PR which 
>>> makes ‘final’ in protocol extensions an error in Swift 4 mode (and a 
>>> warning in 3), I would merge it.
>>> 
>>> FWIW that there is one restriction around the direct dispatch here we want 
>>> to lift, but it’s not related to this proposal.
>>> 
>>> If you have a base class conforming to a protocol using default 
>>> requirements, eg
>>> 
>>>   protocol Proto { func f() }
>>>   extension Proto { func f() { } }
>>> 
>>>   class Base : Proto {}
>>> 
>>> Currently the witness table for Base : Proto directly references the 
>>> extension method Proto.f.
>>> 
>>> We want to allow this, at least inside the module:
>>> 
>>> class Derived {
>>>   override func f() {} // does not work currently
>>> }
>>> 
>>> This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing 
>>> at the extension method. The conformance will dispatch through the vtable 
>>> instead of directly calling the extension method.
>> 
>> Would this allow the override to call `Proto.f` through super?
>> 
>>> 
>>> Slava
>>> 
 On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution 
 > wrote:
 
 Hey Folks, This draft proposal addresses starter bug SR-1762. I believe 
 this is in scope for Swift 4 since it impacts source compatibility. It's 
 not a very exciting proposal, but I think it will help make Swift a little 
 more consistent.
 
 https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7 
 
 https://bugs.swift.org/browse/SR-1762 
 
 
 Thanks
 
 Brian
 Introduction
 
 This proposal suggests removing support for the final keyword when 
 declaring a function in a protocol extension. The presence of the final 
 keyword does not currently generate an error message, and it does not 
 actually modify the dispatch behavior in any way.
 
  
 Motivation
 
 In the original protocol model of Swift, a developer could use the final 
 keyword when declaring a function in a protocol extension to ensure the 
 function could not be overridden. This keyword has no use in Swift's 
 current protocol model, since functions in protocol extensions can not be 
 overridden and will always use direct dispatch.
 
  
 

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

[Brian King via swift-evolution]

I have a change ready and can turn it into a PR. Jordan mentioned in the
bug that this would require a SE proposal, but looking at this as a bug in
the current implementation rather than a change in the language makes
sense. It certainly is trivial enough, and doesn't change any semantics, so
I'll make a PR today.

If we do want a proposal to move forward Erica gave me some great language
updates that I can address.

The other bug https://bugs.swift.org/browse/SR-103 looks like it's been
getting some attention and debate on if it should go through the evolution
process.

Brian


On Thu, Mar 9, 2017 at 3:23 AM, Slava Pestov  wrote:

> I think the fact that the type checker permits ‘final’ to appear inside
> protocol extensions is an oversight and this probably does not even warrant
> a proposal. I don’t think allowing this was ever part of the conceptual
> model of protocol extensions at any point in time (if you recall they were
> introduced ‘recently’, in Swift 2). If someone put together a PR which
> makes ‘final’ in protocol extensions an error in Swift 4 mode (and a
> warning in 3), I would merge it.
>


> FWIW that there is one restriction around the direct dispatch here we want
> to lift, but it’s not related to this proposal.
>
> If you have a base class conforming to a protocol using default
> requirements, eg
>
>   protocol Proto { func f() }
>   extension Proto { func f() { } }
>
>   class Base : Proto {}
>
> Currently the witness table for Base : Proto directly references the
> extension method Proto.f.
>
> We want to allow this, at least inside the module:
>
> class Derived {
>   override func f() {} // does not work currently
> }
>
> This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’,
> pointing at the extension method. The conformance will dispatch through the
> vtable instead of directly calling the extension method.
>
> Slava
>
> On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hey Folks, This draft proposal addresses starter bug SR-1762. I believe
> this is in scope for Swift 4 since it impacts source compatibility. It's
> not a very exciting proposal, but I think it will help make Swift a little
> more consistent.
>
> https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7
> https://bugs.swift.org/browse/SR-1762
>
> Thanks
>
> Brian
> Introduction
>
> This proposal suggests removing support for the final keyword when
> declaring a function in a protocol extension. The presence of the final 
> keyword
> does not currently generate an error message, and it does not actually
> modify the dispatch behavior in any way.
>
> 
> Motivation
>
> In the original protocol model of Swift, a developer could use the final 
> keyword
> when declaring a function in a protocol extension to ensure the function
> could not be overridden. This keyword has no use in Swift's current
> protocol model, since functions in protocol extensions can not be
> overridden and will always use direct dispatch.
>
> Detailed
> design
>
> The compiler should generate an error or warning when the final keyword
> is used on a function declaration inside of a protocol extension. This is
> consistent with the use of final in structs and enumerations.
>
> Source
> compatibility
>
> This change will impact source compatibility. To maintain compatibility
> with Swift 3, a warning will be generated in Swift 3 mode instead of an
> error message.
>
> Effect
> on ABI stability
>
> This has no effect on ABI stability
>
> Effect
> on API resilience
>
> This has no effect on API resilience
>
> Alternatives
> considered
> The only alternative would be to not fix this bug
> ___
> 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] Anonymous Enum Cases

[Matthew Johnson via swift-evolution]

+1.  Combining this with overloaded cases will be very nice for some kinds of 
enums.

Sent from my iPad

> On Mar 8, 2017, at 9:09 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> During review for the first revision of SE-0155, Dave Abraham suggested that 
> we should allow enum cases without base names. So here’s a (rough) draft of a 
> proposal for this feature. Please read and share your thoughts!
> 
> # Anonymous Enum Cases
> 
> * Proposal: [SE-](-anonymous-enum-cases.md)
> * Authors: [Daniel Duan](https://github.com/dduan)
> * Review Manager: TBD
> * Status: **Awaiting review**
> 
> ## Introduction
> 
> This proposal adds anonymous cases to Swift's enum.
> 
> ## Motivation
> 
> Naming things is a tough task for programmer. This is one merit of features 
> such
> as anonymous function and tuples: users can use them in a limited scope and 
> skip
> the mind burden of coming up with names. We can expand this convenience to 
> enums
> by allowing user to declare, construct and pattern match anonymous cases.
> 
> ## Proposed solution
> 
> Add anonymous cases to Swift's enum.
> 
> ## Detailed design
> 
> Anonymous enums can be declared with this syntax:
> 
> ```swift
> enum Foo {
>case (Int)
>case (label0: Int, label1: String)
> }
> ```
> 
> Anonymous case without any associated values is not allowed.
> 
> Anonymous case values can be constructed with constructors with the enum's 
> name
> being their base name. Following the example:
> 
> ```swift
> Foo(42) // constructs `Foo` case corresponding to `case (Int)`
> Foo(label0: 0, labe1: "hello") // value of type Foo, 2nd case.
> Foo(label0: label1:)(0, "hello") // constructs the same value, SE-0155 syntax
> ```
> 
> For pattern matching, rules remain the same as regular cases, execpt, 
> naturally,
> the base name shall be skipped.
> 
> ```swift
> case .(let x) = Foo(42) // x has value 42
> case .(label0: let a, label1: let b) = Foo(label0: 0, label1: "hello") // ok
> ```
> 
> ## Source compatibility
> 
> This is additive. It's fully source compatible with Swift 3.
> 
> ## Effect on ABI stability
> 
> This feature adds new possibilities to symbols exposed by enum declarations.
> 
> ## Effect on API resilience
> 
> ## Alternatives considered
> 
> It may seem "regular" to make user use `_` in place of base name in
> declarations. The author think that's a perspective that only makes sense for
> language designer/compiler implementors. To a user, the syntax chosen in this
> proposal is clear and succinct.
> 
> 
> 
> ___
> 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] Normalize Enum Case Representation (rev. 2)

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 9, 2017, at 2:31 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan  wrote:
>> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to 
>> incorporate some of the responses into the proposal.
>> 
>>> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu  wrote:
>>> 
>>> The rendered version differs from the text appended to your message. I'll 
>>> assume the more fully fleshed out version is what you intend to submit. 
>>> Three comments/questions:
>>> 
>>> Enum Case "Overloading"
>>> 
>>> An enum may contain cases with the same full name but with associated 
>>> values of different types. For example:
>>> 
>>> enum Expr {
>>> case literal(Bool)
>>> case literal(Int)
>>> }
>>> The above cases have overloaded constructors, which follow the same rules 
>>> as functions at call site for disambiguation:
>>> 
>>> // It's clear which case is being constructed in the following.
>>> let aBool: Expr = .literal(false)
>>> let anInt: Expr = .literal(42)
>>> User must specify an as expression in sub-patterns in pattern matching, in 
>>> order to match with such cases:
>>> 
>>> case .literal(let value) // this is ambiguous
>>> case .literal(let value as Bool) // matches `case literal(Bool)`
>>> 
>>> Comment/question 1: Here, why aren't you proposing to allow `case 
>>> .literal(let value: Bool)`? For one, it would seem to be more consistent.
>> 
>> The example in proposal doesn't include any labels. Are you suggesting two 
>> colons for sub-patterns with labels? Like `case .literal(value: let value: 
>> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.
> 
> That does look jarring. But hmm.
>  
>>> Second, since we still have some use cases where there's Obj-C bridging 
>>> magic with `as`, using `as` in this way may run into ambiguity issues if 
>>> (for example) you have two cases, one with associated value of type 
>>> `String` and the other of type `NSString`.
>> 
>> Either this should be rejected at declaration, or we need a way to accept a 
>> "pre-magic" resolution at pattern matching, when this scenarios is at hand.
> 
> Or we align pattern matching to function syntax and have such cases 
> disambiguated in that way (see below).
>  
>> I'm on the phone so I can't verify. Wouldn't function overloading face a 
>> similar problem?
>> 
>>> Also, since enum cases are to be like functions, I assume that the more 
>>> verbose `as` version would work for free: `case .literal(let value) as 
>>> (Bool) -> Expr`?
>>> 
>> 
>> This is not being proposed. When a user sees/authors a case, their 
>> expectation for the declared case constructor should resemble that of a 
>> function. Pattern matching was considered separately since it's not 
>> relatable syntactically.
> 
> This requires justification. If enum cases are to be like functions, then the 
> logical expectation is that pattern matching should work in that way too. I 
> see no rationale to undergird your claim that pattern matching is "not 
> relatable syntactically." Allowing `case .literal(let value) as (Bool) -> 
> Expr` would solve the issue above, as well as provide more flexibility with 
> the issues below.
>>> Alternative Payload-less Case Declaration
>>> 
>>> In Swift 3, the following syntax is valid:
>>> 
>>> enum Tree {
>>> case leaf() // the type of this constructor is confusing!
>>> }
>>> Tree.leaf has a very unexpected type to most Swift users: (()) -> Tree
>>> 
>>> We propose this syntax declare the "bare" case instead. So it's going to be 
>>> the equivalent of
>>> 
>>> enum Tree {
>>> case leaf // `()` is optional and does the same thing.
>>> }
>>> 
>>> 
>>> Comment/question 2: First, if associated values are not to be modeled as 
>>> tuples, for backwards compatibility the rare uses of `case leaf()` should 
>>> be migrated to `case leaf(())`.
>>> 
>> 
>> Yes,
> 
> Cool.
>  
>> and when user uses a arbitrary name when they should have used a label, or 
>> when labels are misspelled, the compiler should suggest the correct labels.
> 
> As below, I disagree with this restriction very strongly.
>  
>> I wasn't sure how much of migrator related thing should go into a proposal. 
>> Perhaps there should be more.
>>> Second, to be clear, you are _not_ proposing additional sugar so that a 
>>> case without an associated value be equivalent to a case that has an 
>>> associated value of type `Void`, correct? You are saying that, with your 
>>> proposal, both `case leaf()` and `case leaf` would be regarded as being of 
>>> type `() -> Tree` instead of the current `(()) -> Tree`?
>>> 
>> 
>> Correct. I'm _not_ proposing implicit `Void`.
>>> [The latter (i.e. `() -> Tree`) seems entirely fine. The former (i.e. 
>>> additional sugar for `(()) -> Tree`) seems mostly fine, except that it 
>>> would introduce an inconsistency with raw values that IMO is awkward. That 
>>> is, if I have 

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Ricardo Parada via swift-evolution]

> On Feb 26, 2017, at 10:00 PM, Derrick Ho via swift-evolution 
>  wrote:
> 
> foo(["a", "b", "c"] as String...) 

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

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> I think the fact that the type checker permits ‘final’ to appear inside 
> protocol extensions is an oversight and this probably does not even warrant a 
> proposal. I don’t think allowing this was ever part of the conceptual model 
> of protocol extensions at any point in time (if you recall they were 
> introduced ‘recently’, in Swift 2). If someone put together a PR which makes 
> ‘final’ in protocol extensions an error in Swift 4 mode (and a warning in 3), 
> I would merge it.
> 
> FWIW that there is one restriction around the direct dispatch here we want to 
> lift, but it’s not related to this proposal.
> 
> If you have a base class conforming to a protocol using default requirements, 
> eg
> 
>   protocol Proto { func f() }
>   extension Proto { func f() { } }
> 
>   class Base : Proto {}
> 
> Currently the witness table for Base : Proto directly references the 
> extension method Proto.f.
> 
> We want to allow this, at least inside the module:
> 
> class Derived {
>   override func f() {} // does not work currently
> }
> 
> This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing 
> at the extension method. The conformance will dispatch through the vtable 
> instead of directly calling the extension method.

Would this allow the override to call `Proto.f` through super?

> 
> Slava
> 
>> On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution 
>>  wrote:
>> 
>> Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this 
>> is in scope for Swift 4 since it impacts source compatibility. It's not a 
>> very exciting proposal, but I think it will help make Swift a little more 
>> consistent.
>> 
>> https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7
>> https://bugs.swift.org/browse/SR-1762
>> 
>> Thanks
>> 
>> Brian
>> Introduction
>> 
>> This proposal suggests removing support for the final keyword when declaring 
>> a function in a protocol extension. The presence of the final keyword does 
>> not currently generate an error message, and it does not actually modify the 
>> dispatch behavior in any way.
>> 
>> 
>> Motivation
>> 
>> In the original protocol model of Swift, a developer could use the final 
>> keyword when declaring a function in a protocol extension to ensure the 
>> function could not be overridden. This keyword has no use in Swift's current 
>> protocol model, since functions in protocol extensions can not be overridden 
>> and will always use direct dispatch.
>> 
>> 
>> Detailed design
>> 
>> The compiler should generate an error or warning when the final keyword is 
>> used on a function declaration inside of a protocol extension. This is 
>> consistent with the use of final in structs and enumerations.
>> 
>> 
>> Source compatibility
>> 
>> This change will impact source compatibility. To maintain compatibility with 
>> Swift 3, a warning will be generated in Swift 3 mode instead of an error 
>> message.
>> 
>> 
>> Effect on ABI stability
>> 
>> This has no effect on ABI stability
>> 
>> 
>> Effect on API resilience
>> 
>> This has no effect on API resilience
>> 
>> 
>> Alternatives considered
>> 
>> The only alternative would be to not fix this bug
>> 
>> ___
>> 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] [Pitch] Allow numerical keywords in member references

[Ross O'Brien via swift-evolution]

I could see a purpose for identifiers which started numbers but weren't
entirely numerical.
e.g.
enum Dimensions { case `2D`, `3D` }
enum DiceRoll { case d6, `2d6` }
func roll(dice: DiceRoll) -> Int { ... }
roll(.`2d6`)

I'm not sure I see one for identifiers which are entirely numerical.

Ross


On Thu, Mar 9, 2017 at 8:05 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> My point would be to have a exact set of possible numerical cases. The
> issue with numerical cases is that they don’t have to be ordered and they
> could also be overlapping with other subsystems (by subsystem I mean a
> subsystem of your particular project).
>
> Even if we had the ability to limit the range of numerical types like Int,
> we still might not be able to exclude inner values for that range, which
> makes RawRepresentable not quite efficient to work with. Numerical enum
> cases on the other hand could solve that issue elegantly.
>
> I see the reason for types other because of FP and integer literals, but I
> don’t see why we couldn’t have numerical enum cases.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. März 2017 um 08:52:34, Slava Pestov (spes...@apple.com) schrieb:
>
>
> On Mar 8, 2017, at 11:46 PM, Adrian Zubarev  com> wrote:
>
> I don’t have more precise examples except something like TCP socket error
> codes as an enum.
>
> I would expect that the error code is available as a computed property of
> the enum value, perhaps as its raw value or something else. I would not
> expect it to be part of the enum case *name*. What significance does the
> numeric code have to the reader of the code, and when do you ever want to
> permanently freeze error codes in an API like this?
>
> Note that even Unix errno error codes are not standardized across unices
> or even different architectures running Linux; only their names are.
>
> Slava
>
> The example with the number literal is actually really good, because it
> also shows the bad sides of the pitch. However we could allow numerical
> enum cases without any issues right?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. März 2017 um 08:41:13, Slava Pestov (spes...@apple.com) schrieb:
>
>
> On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I forget to mention, this should be also valid:
>
> let `42` = 42
>
> print(`42`)
>
> struct A {
> let `0` = 0
> }
>
> let number = A().0
>
>
> -1
>
> This seems really confusing.
>
> extension Int { var `0`: Int { return 0 } }
>
> 3.0 // is this a float literal?
> 3 .0 // member access?
> .0 // this is actually a contextual member access, and not a literal ‘0.0’?
>
>  I’d prefer if .0, .1, … were reserved for tuple fields; .0 is already not
> very descriptive, but at the very least if you see it in source code you
> know you have a tuple type and not something else.
>
> Also the compiler’s name mangling relies on the fact that identifiers
> never begin with a numeric character or symbol.
>
> Can you give a motivating example where allowing an identifier to start
> with a number actually helps readability?
>
> Slava
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. März 2017 um 08:24:54, Adrian Zubarev (adrian.zubarev@devandartist.
> com) schrieb:
>
> Hi Swift community, I’d like to pitch this idea again.
>
> Swift already has the pitched feature, but it is exclusive for tuples only.
>  *SE–0071* allowed the use of keywords after the . in a member access,
> except for those keywords that have special meaning by using back-ticks.
> However, members starting with numbers are not special keywords and as
> already mentioned, numerical members are already allowed in tuples.
>
> I propose to extend that capability to the whole language and make that
> behavior consistent. To disambiguate members starting with a number one
> would need to use back-ticks.
>
> // Enum
> enum ErrorCode : String {
>
> case `2345` = "my description for 2345"
> case `123a` = "my description for 123a"
> case `123b` = "my description for 123b"
> }
>
> let code = ErrorCode.2345
>
> // Function
> func `42foo`(label: Type, `12345`: Type, `0987something`: Type) { … }
>
> // Tuple
> (`1`: Int, `2`: Int)
>
> My question is: would that be in scope for Swift 4?
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

[Rudolf Adamkovič via swift-evolution]

That’s correct, thanks for the correction. The rule only applies to parameters 
with argument labels.

But still, we’d lost this guarantee of self-documenting, type-safe 
non-emptiness if arbitrary arrays can be passed to variadic parameters with 
argument labels.

R+

> On 8 Mar 2017, at 23:42, Derrick Ho  wrote:
> 
> Rudolf, I don't believe that is a rule.
> 
> One example includes NSLog()
> 
> In which the first parameter is a format string and the second is a variadic 
> argument. The second one can be omitted.
> On Wed, Mar 8, 2017 at 5:09 PM Rudolf Adamkovič via swift-evolution 
> > wrote:
> Correct me if I’m wrong but a variadic argument is guaranteed to have one or 
> more elements in the array. Isn’t that the case? As an example, consider the 
> following initializer:
> 
> public init(state: State, actions: Action...) {
> // ...
> }
> 
> Here, I can count on actions to be a non-empty array. It’s self-documenting 
> and type-safe. How would this work if arrays are (implicitly or explicitly) 
> convertible to variadic arguments?
> 
> R+
> 
>> On 26 Feb 2017, at 17:26, Derrick Ho via swift-evolution 
>> > wrote:
>> 
> 
>> In swift, a variadic argument can become an array without too much effort.
>> 
>> func foo(_ va: String...) {
>>let a: [String] = va
>> }
>> 
>> However, it seems odd to me that an array can not be converted into a 
>> variadic argument
>> 
>> foo(["a", "b", "c"]) // <-error
>> foo("a", "b", "c") // no error
>> 
>> Other people have wondered about this too. 
>> 
>> 
>> According to this thread  
>> Doug Gregor says it is due to some type ambiguity. with Generics.
>> 
>> If type ambiguity is the issue, Do we have the option to cast it to the 
>> correct type?
>> 
>> foo(["a", "b", "c"] as String...) // <- error.  doesn't consider String... 
>> to be a type.
>> 
>> What does the community think? Should we be granted some mechanism to turn 
>> an array into a variadic argument?
> 
>> ___
>> 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] Custom Literals

[Daniel Leping via swift-evolution]

I'm quite positive we need it. The question is in which way.

On Thu, 9 Mar 2017 at 2:24 David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

> The conversation kinda died out over the new year, and a quick search
> didn’t come up with an answer... Did we decide that adding user-definable
> literal types was out of scope for Swift 4?
>
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[Xiaodi Wu via swift-evolution]

On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan  wrote:

> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to
> incorporate some of the responses into the proposal.
>
> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu  wrote:
>
> The rendered version differs from the text appended to your message. I'll
> assume the more fully fleshed out version is what you intend to submit.
> Three comments/questions:
>
> Enum Case "Overloading"
>
> An enum may contain cases with the same full name but with associated
> values of different types. For example:
>
> enum Expr {
> case literal(Bool)
> case literal(Int)
> }
>
> The above cases have overloaded constructors, which follow the same rules
> as functions at call site for disambiguation:
>
> // It's clear which case is being constructed in the following.let aBool: 
> Expr = .literal(false)let anInt: Expr = .literal(42)
>
> User must specify an as expression in sub-patterns in pattern matching,
> in order to match with such cases:
>
> case .literal(let value) // this is ambiguouscase .literal(let value as Bool) 
> // matches `case literal(Bool)`
>
>
> Comment/question 1: Here, why aren't you proposing to allow `case
> .literal(let value: Bool)`? For one, it would seem to be more consistent.
>
>
> The example in proposal doesn't include any labels. Are you suggesting two
> colons for sub-patterns with labels? Like `case .literal(value: let value:
> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.
>

That does look jarring. But hmm.


> Second, since we still have some use cases where there's Obj-C bridging
> magic with `as`, using `as` in this way may run into ambiguity issues if
> (for example) you have two cases, one with associated value of type
> `String` and the other of type `NSString`.
>
>
> Either this should be rejected at declaration, or we need a way to accept
> a "pre-magic" resolution at pattern matching, when this scenarios is at
> hand.
>

Or we align pattern matching to function syntax and have such cases
disambiguated in that way (see below).


> I'm on the phone so I can't verify. Wouldn't function overloading face a
> similar problem?
>
> Also, since enum cases are to be like functions, I assume that the more
> verbose `as` version would work for free: `case .literal(let value) as
> (Bool) -> Expr`?
>
>
> This is not being proposed. When a user sees/authors a case, their
> expectation for the declared case constructor should resemble that of a
> function. Pattern matching was considered separately since it's not
> relatable syntactically.
>

This requires justification. If enum cases are to be like functions, then
the logical expectation is that pattern matching should work in that way
too. I see no rationale to undergird your claim that pattern matching is
"not relatable syntactically." Allowing `case .literal(let value) as (Bool)
-> Expr` would solve the issue above, as well as provide more flexibility
with the issues below.

>
> Alternative
> Payload-less Case Declaration
>
> In Swift 3, the following syntax is valid:
>
> enum Tree {
> case leaf() // the type of this constructor is confusing!}
>
> Tree.leaf has a very unexpected type to most Swift users: (()) -> Tree
>
> We propose this syntax declare the "bare" case instead. So it's going to
> be the equivalent of
>
> enum Tree {
> case leaf // `()` is optional and does the same thing.}
>
>
> Comment/question 2: First, if associated values are not to be modeled as
> tuples, for backwards compatibility the rare uses of `case leaf()` should
> be migrated to `case leaf(())`.
>
> Yes,
>

Cool.


> and when user uses a arbitrary name when they should have used a label, or
> when labels are misspelled, the compiler should suggest the correct labels.
>

As below, I disagree with this restriction very strongly.


> I wasn't sure how much of migrator related thing should go into a
> proposal. Perhaps there should be more.
>
> Second, to be clear, you are _not_ proposing additional sugar so that a
> case without an associated value be equivalent to a case that has an
> associated value of type `Void`, correct? You are saying that, with your
> proposal, both `case leaf()` and `case leaf` would be regarded as being of
> type `() -> Tree` instead of the current `(()) -> Tree`?
>
> Correct. I'm _not_ proposing implicit `Void`.
>
> [The latter (i.e. `() -> Tree`) seems entirely fine. The former (i.e.
> additional sugar for `(()) -> Tree`) seems mostly fine, except that it
> would introduce an inconsistency with raw values that IMO is awkward. That
> is, if I have `enum Foo { case bar }`, it would make case `bar` have
> implied associated type `Void`; but, if I have `enum Foo: Int { case bar
> }`, would case `bar` have raw value `0` of type `Int` as well as associated
> value 

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

[Slava Pestov via swift-evolution]

I think the fact that the type checker permits ‘final’ to appear inside 
protocol extensions is an oversight and this probably does not even warrant a 
proposal. I don’t think allowing this was ever part of the conceptual model of 
protocol extensions at any point in time (if you recall they were introduced 
‘recently’, in Swift 2). If someone put together a PR which makes ‘final’ in 
protocol extensions an error in Swift 4 mode (and a warning in 3), I would 
merge it.

FWIW that there is one restriction around the direct dispatch here we want to 
lift, but it’s not related to this proposal.

If you have a base class conforming to a protocol using default requirements, eg

  protocol Proto { func f() }
  extension Proto { func f() { } }

  class Base : Proto {}

Currently the witness table for Base : Proto directly references the extension 
method Proto.f.

We want to allow this, at least inside the module:

class Derived {
  override func f() {} // does not work currently
}

This will mean that ‘Proto.f’ will appear in the vtable of ‘Base’, pointing at 
the extension method. The conformance will dispatch through the vtable instead 
of directly calling the extension method.

Slava

> On Mar 7, 2017, at 7:23 PM, Brian King via swift-evolution 
>  wrote:
> 
> Hey Folks, This draft proposal addresses starter bug SR-1762. I believe this 
> is in scope for Swift 4 since it impacts source compatibility. It's not a 
> very exciting proposal, but I think it will help make Swift a little more 
> consistent.
> 
> https://gist.github.com/KingOfBrian/6f20c566114ac0ef54c8092d80e54ee7 
> 
> https://bugs.swift.org/browse/SR-1762 
> 
> Thanks
> 
> Brian
> Introduction
> 
> This proposal suggests removing support for the final keyword when declaring 
> a function in a protocol extension. The presence of the final keyword does 
> not currently generate an error message, and it does not actually modify the 
> dispatch behavior in any way.
> 
> 
>  
> Motivation
> 
> In the original protocol model of Swift, a developer could use the final 
> keyword when declaring a function in a protocol extension to ensure the 
> function could not be overridden. This keyword has no use in Swift's current 
> protocol model, since functions in protocol extensions can not be overridden 
> and will always use direct dispatch.
> 
> 
>  
> Detailed
>  design
> 
> The compiler should generate an error or warning when the final keyword is 
> used on a function declaration inside of a protocol extension. This is 
> consistent with the use of final in structs and enumerations.
> 
> 
>  
> Source
>  compatibility
> 
> This change will impact source compatibility. To maintain compatibility with 
> Swift 3, a warning will be generated in Swift 3 mode instead of an error 
> message.
> 
> 
>  
> Effect
>  on ABI stability
> 
> This has no effect on ABI stability
> 
> 
>  
> Effect
>  on API resilience
> 
> This has no effect on API resilience
> 
> 
>  
> Alternatives
>  considered
> 
> The only alternative would be to not fix this bug
> 
> ___
> 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] Normalize Enum Case Representation (rev. 2)

[Daniel Duan via swift-evolution]

> On Mar 9, 2017, at 12:06 AM, David Hart  wrote:
> 
> 
>> On 9 Mar 2017, at 08:07, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to 
>> incorporate some of the responses into the proposal.
>> 
>>> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu  wrote:
>>> 
>>> The rendered version differs from the text appended to your message. I'll 
>>> assume the more fully fleshed out version is what you intend to submit. 
>>> Three comments/questions:
>>> 
>>> Enum Case "Overloading"
>>> 
>>> An enum may contain cases with the same full name but with associated 
>>> values of different types. For example:
>>> 
>>> enum Expr {
>>> case literal(Bool)
>>> case literal(Int)
>>> }
>>> The above cases have overloaded constructors, which follow the same rules 
>>> as functions at call site for disambiguation:
>>> 
>>> // It's clear which case is being constructed in the following.
>>> let aBool: Expr = .literal(false)
>>> let anInt: Expr = .literal(42)
>>> User must specify an as expression in sub-patterns in pattern matching, in 
>>> order to match with such cases:
>>> 
>>> case .literal(let value) // this is ambiguous
>>> case .literal(let value as Bool) // matches `case literal(Bool)`
>>> 
>>> Comment/question 1: Here, why aren't you proposing to allow `case 
>>> .literal(let value: Bool)`? For one, it would seem to be more consistent.
>> 
>> The example in proposal doesn't include any labels. Are you suggesting two 
>> colons for sub-patterns with labels? Like `case .literal(value: let value: 
>> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.
> 
> No, I think he was proposing replicating variable declaration syntax, where 
> the colon is used preceding the type (instead of using as):
> 
> let value: Bool = ...

We'd still need a way for user to bind a matching value to a name other than 
the label... I do realize that this would not be a problem if we drop the 
mandate that label must appear _somewhere_ in the pattern. Hmmm

>>> Second, since we still have some use cases where there's Obj-C bridging 
>>> magic with `as`, using `as` in this way may run into ambiguity issues if 
>>> (for example) you have two cases, one with associated value of type 
>>> `String` and the other of type `NSString`.
>> 
>> Either this should be rejected at declaration, or we need a way to accept a 
>> "pre-magic" resolution at pattern matching, when this scenarios is at hand. 
>> I'm on the phone so I can't verify. Wouldn't function overloading face a 
>> similar problem?
>> 
>>> Also, since enum cases are to be like functions, I assume that the more 
>>> verbose `as` version would work for free: `case .literal(let value) as 
>>> (Bool) -> Expr`?
>>> 
>> 
>> This is not being proposed. When a user sees/authors a case, their 
>> expectation for the declared case constructor should resemble that of a 
>> function. Pattern matching was considered separately since it's not 
>> relatable syntactically.
>>> Alternative Payload-less Case Declaration
>>> 
>>> In Swift 3, the following syntax is valid:
>>> 
>>> enum Tree {
>>> case leaf() // the type of this constructor is confusing!
>>> }
>>> Tree.leaf has a very unexpected type to most Swift users: (()) -> Tree
>>> 
>>> We propose this syntax declare the "bare" case instead. So it's going to be 
>>> the equivalent of
>>> 
>>> enum Tree {
>>> case leaf // `()` is optional and does the same thing.
>>> }
>>> 
>>> 
>>> Comment/question 2: First, if associated values are not to be modeled as 
>>> tuples, for backwards compatibility the rare uses of `case leaf()` should 
>>> be migrated to `case leaf(())`.
>>> 
>> Yes, and when user uses a arbitrary name when they should have used a label, 
>> or when labels are misspelled, the compiler should suggest the correct 
>> labels. I wasn't sure how much of migrator related thing should go into a 
>> proposal. Perhaps there should be more.
>>> Second, to be clear, you are _not_ proposing additional sugar so that a 
>>> case without an associated value be equivalent to a case that has an 
>>> associated value of type `Void`, correct? You are saying that, with your 
>>> proposal, both `case leaf()` and `case leaf` would be regarded as being of 
>>> type `() -> Tree` instead of the current `(()) -> Tree`?
>>> 
>> Correct. I'm _not_ proposing implicit `Void`.
>>> [The latter (i.e. `() -> Tree`) seems entirely fine. The former (i.e. 
>>> additional sugar for `(()) -> Tree`) seems mostly fine, except that it 
>>> would introduce an inconsistency with raw values that IMO is awkward. That 
>>> is, if I have `enum Foo { case bar }`, it would make case `bar` have 
>>> implied associated type `Void`; but, if I have `enum Foo: Int { case bar 
>>> }`, would case `bar` have raw value `0` of type `Int` as well as associated 
>>> value `()` of type `Void`?]
>>> 
>>> 
>>> Pattern Consistency
>>> 
>>> 

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

[David Hart via swift-evolution]

> On 9 Mar 2017, at 08:07, Daniel Duan via swift-evolution 
>  wrote:
> 
> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to 
> incorporate some of the responses into the proposal.
> 
> On Mar 8, 2017, at 9:56 PM, Xiaodi Wu  > wrote:
> 
>> The rendered version differs from the text appended to your message. I'll 
>> assume the more fully fleshed out version is what you intend to submit. 
>> Three comments/questions:
>> 
>> Enum Case "Overloading"
>> 
>> An enum may contain cases with the same full name but with associated values 
>> of different types. For example:
>> 
>> enum Expr {
>> case literal(Bool)
>> case literal(Int)
>> }
>> The above cases have overloaded constructors, which follow the same rules as 
>> functions at call site for disambiguation:
>> 
>> // It's clear which case is being constructed in the following.
>> let aBool: Expr = .literal(false)
>> let anInt: Expr = .literal(42)
>> User must specify an as expression in sub-patterns in pattern matching, in 
>> order to match with such cases:
>> 
>> case .literal(let value) // this is ambiguous
>> case .literal(let value as Bool) // matches `case literal(Bool)`
>> 
>> Comment/question 1: Here, why aren't you proposing to allow `case 
>> .literal(let value: Bool)`? For one, it would seem to be more consistent.
> 
> The example in proposal doesn't include any labels. Are you suggesting two 
> colons for sub-patterns with labels? Like `case .literal(value: let value: 
> Bool)`?  This looks jarring. But I'm definitely open to other suggestions.

No, I think he was proposing replicating variable declaration syntax, where the 
colon is used preceding the type (instead of using as):

let value: Bool = ...

>> Second, since we still have some use cases where there's Obj-C bridging 
>> magic with `as`, using `as` in this way may run into ambiguity issues if 
>> (for example) you have two cases, one with associated value of type `String` 
>> and the other of type `NSString`.
> 
> Either this should be rejected at declaration, or we need a way to accept a 
> "pre-magic" resolution at pattern matching, when this scenarios is at hand. 
> I'm on the phone so I can't verify. Wouldn't function overloading face a 
> similar problem?
> 
>> Also, since enum cases are to be like functions, I assume that the more 
>> verbose `as` version would work for free: `case .literal(let value) as 
>> (Bool) -> Expr`?
>> 
> 
> This is not being proposed. When a user sees/authors a case, their 
> expectation for the declared case constructor should resemble that of a 
> function. Pattern matching was considered separately since it's not relatable 
> syntactically.
>>  
>> Alternative
>>  Payload-less Case Declaration
>> 
>> In Swift 3, the following syntax is valid:
>> 
>> enum Tree {
>> case leaf() // the type of this constructor is confusing!
>> }
>> Tree.leaf has a very unexpected type to most Swift users: (()) -> Tree
>> 
>> We propose this syntax declare the "bare" case instead. So it's going to be 
>> the equivalent of
>> 
>> enum Tree {
>> case leaf // `()` is optional and does the same thing.
>> }
>> 
>> 
>> Comment/question 2: First, if associated values are not to be modeled as 
>> tuples, for backwards compatibility the rare uses of `case leaf()` should be 
>> migrated to `case leaf(())`.
>> 
> Yes, and when user uses a arbitrary name when they should have used a label, 
> or when labels are misspelled, the compiler should suggest the correct 
> labels. I wasn't sure how much of migrator related thing should go into a 
> proposal. Perhaps there should be more.
>> Second, to be clear, you are _not_ proposing additional sugar so that a case 
>> without an associated value be equivalent to a case that has an associated 
>> value of type `Void`, correct? You are saying that, with your proposal, both 
>> `case leaf()` and `case leaf` would be regarded as being of type `() -> 
>> Tree` instead of the current `(()) -> Tree`?
>> 
> Correct. I'm _not_ proposing implicit `Void`.
>> [The latter (i.e. `() -> Tree`) seems entirely fine. The former (i.e. 
>> additional sugar for `(()) -> Tree`) seems mostly fine, except that it would 
>> introduce an inconsistency with raw values that IMO is awkward. That is, if 
>> I have `enum Foo { case bar }`, it would make case `bar` have implied 
>> associated type `Void`; but, if I have `enum Foo: Int { case bar }`, would 
>> case `bar` have raw value `0` of type `Int` as well as associated value `()` 
>> of type `Void`?]
>> 
>> 
>>  
>> Pattern
>>  Consistency
>> 
>> (The following enum will be used throughout code snippets in this 

Re: [swift-evolution] [Pitch] Allow numerical keywords in member references

[Adrian Zubarev via swift-evolution]

My point would be to have a exact set of possible numerical cases. The issue 
with numerical cases is that they don’t have to be ordered and they could also 
be overlapping with other subsystems (by subsystem I mean a subsystem of your 
particular project).

Even if we had the ability to limit the range of numerical types like Int, we 
still might not be able to exclude inner values for that range, which makes 
RawRepresentable not quite efficient to work with. Numerical enum cases on the 
other hand could solve that issue elegantly.

I see the reason for types other because of FP and integer literals, but I 
don’t see why we couldn’t have numerical enum cases.



-- 
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 08:52:34, Slava Pestov (spes...@apple.com) schrieb:


On Mar 8, 2017, at 11:46 PM, Adrian Zubarev  
wrote:

I don’t have more precise examples except something like TCP socket error codes 
as an enum.

I would expect that the error code is available as a computed property of the 
enum value, perhaps as its raw value or something else. I would not expect it 
to be part of the enum case *name*. What significance does the numeric code 
have to the reader of the code, and when do you ever want to permanently freeze 
error codes in an API like this?

Note that even Unix errno error codes are not standardized across unices or 
even different architectures running Linux; only their names are.

Slava

The example with the number literal is actually really good, because it also 
shows the bad sides of the pitch. However we could allow numerical enum cases 
without any issues right?




-- 
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 08:41:13, Slava Pestov (spes...@apple.com) schrieb:


On Mar 8, 2017, at 11:33 PM, Adrian Zubarev via swift-evolution 
 wrote:

I forget to mention, this should be also valid:

let `42` = 42

print(`42`)

struct A {
let `0` = 0
}

let number = A().0

-1

This seems really confusing.

extension Int { var `0`: Int { return 0 } }

3.0 // is this a float literal?
3 .0 // member access?
.0 // this is actually a contextual member access, and not a literal ‘0.0’?

 I’d prefer if .0, .1, … were reserved for tuple fields; .0 is already not very 
descriptive, but at the very least if you see it in source code you know you 
have a tuple type and not something else.

Also the compiler’s name mangling relies on the fact that identifiers never 
begin with a numeric character or symbol.

Can you give a motivating example where allowing an identifier to start with a 
number actually helps readability?

Slava




-- 
Adrian Zubarev
Sent with Airmail

Am 9. März 2017 um 08:24:54, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Hi Swift community, I’d like to pitch this idea again.

Swift already has the pitched feature, but it is exclusive for tuples only. 
SE–0071 allowed the use of keywords after the . in a member access, except for 
those keywords that have special meaning by using back-ticks. However, members 
starting with numbers are not special keywords and as already mentioned, 
numerical members are already allowed in tuples.

I propose to extend that capability to the whole language and make that 
behavior consistent. To disambiguate members starting with a number one would 
need to use back-ticks.

// Enum
enum ErrorCode : String {

case `2345` = "my description for 2345"
case `123a` = "my description for 123a"
case `123b` = "my description for 123b"
}

let code = ErrorCode.2345

// Function
func `42foo`(label: Type, `12345`: Type, `0987something`: Type) { … }

// Tuple
(`1`: Int, `2`: Int)
My question is: would that be in scope for Swift 4?



-- 
Adrian Zubarev
Sent with Airmail

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



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