Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

2017-01-24 Thread Bouke Haarsma via swift-evolution 

On 2017-01-24 20:28:30 +, Daniel Dunbar via swift-evolution said:


I am reposting this since the URLs were mangled in the original email.

Hello Swift community,

The review of SE-0149 “ Package Manager Support for Top of Tree 
development" begins now and runs through January 31, 2017. The proposal 
is available here:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md 



Reviews are an important part of the Swift evolution process. All 
reviews should be sent to the swift-build-dev and swift-evolution 
mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the 
review manager. When replying, please try to keep the proposal link at 
the top of the message:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md 



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?
+1. Currently I create the symlinks manually, but that runs into 
issues; for example when trying to update a changed dependency graph.


I'm also interested in how SwiftPM would handle the situation that 
Derrick Ho sketches.


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

Yes.


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

Yes.

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

Very similar to what pip (python) offers. It's a feature that I've used a lot.

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

Quick reading.


More information about the Swift evolution process is available at
  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,
- Daniel


--
-Bouke


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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

2017-01-24 Thread Bouke Haarsma via swift-evolution 

On 2017-01-24 18:18:07 +, Daniel Dunbar via swift-build-dev said:


Hello Swift community,

The review of SE-0150 “ Package Manager Support for branches" begins 
now and runs through January 31, 2017. The proposal is available here:


  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md 



Reviews are an important part of the Swift evolution process. All 
reviews should be sent to the swift-build-dev and swift-evolution 
mailing lists at

  https://lists.swift.org/mailman/listinfo/swift-build-dev
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the 
review manager. When replying, please try to keep the proposal link at 
the top of the message:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md 



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?
This has been a feature request of mine for quite a while now. I'm a 
supporter of this proposal. Also having the actual revision number in 
the pin file is a great way to make sure everyone useses the exact same 
revision (if the pin file is also versioned).


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

Yes.


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

Yes.

	• If you have used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
I've also used pip (python), which something similar. However pip's 
syntax for installing from a branch is more cumbersome and different to 
installing the latest release; e.g. (taken from SO):


  pip install django-oscar-paypal
  pip install 
git+https://github.com/tangentlabs/django-oscar-paypal.git@issue/34/oscar-0.6 



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

Quick reading.


More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

- Daniel

Review Manager
___
swift-build-dev mailing list
swift-build-...@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev



--
-Bouke


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

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

2017-01-24 Thread Robert Widmann via swift-evolution 
Excellent.  I've added your name to the authors list on the gist.  That is the 
version I'll be submitting to evolution soon. 

~Robert Widmann

2017/01/25 0:58、thislooksfun  のメッセージ:

> No problem, it's been inactive for a couple weeks since I've been really 
> busy. And yeah, yours is more thorough. I didn't even consider adding a 
> `testTargets` section. That alone is worth merging.
> 
> -thislooksfun (tlf)
> 
>> On Jan 24, 2017, at 11:55 PM, Robert Widmann  
>> wrote:
>> 
>> Oh, I'm sorry.  I didn't know there was existing work in this space.  
>> Considering this proposal looks like it expands on your earlier work, would 
>> you like to sign on to this and merge the two efforts?
>> 
>> ~Robert Widmann
>> 
>> 2017/01/25 0:47、thislooksfun  のメッセージ:
>> 
>>> As the author of the Add support for test-only dependencies thread, and the 
>>> accompanying draft, this gets a big +1 from me.
>>> 
>>> -thislooksfun (tlf)
>>> 
 On Jan 24, 2017, at 4:32 PM, Robert Widmann via swift-evolution 
  wrote:
 
 Hello Swift Community,
 
 Harlan Haskins and I have been working on libraries to make interacting 
 with LLVM and Clang’s APIs more elegant with native Swift interfaces.  
 While writing up the packages we realized the package manager wouldn’t 
 allow us to specify testing targets and test-only dependencies.  To 
 rectify that, I have attached a draft proposal for adding test-only 
 targets and dependency fields to the Swift Package manager.  This proposal 
 can also be read in gist form.
 
 Cheers,
 
 ~Robert Widmann
 
 Test-Only Package Dependencies and Targets
 Proposal: SE-
 Authors: Harlan Haskins, Robert Widmann
 Review Manager: TBD
 Status: Awaiting review
 Introduction
 
 This proposal reinstates Swift package manager’s ability to fetch 
 dependencies and build targets scoped exclusively to the testing module(s) 
 of a given package.
 
 Swift-evolution thread: Discussion thread topic for that proposal
 
 Motivation
 
 Soon after SE-0019 identified the need for richer test-only dependencies 
 and targets, a decision was made to remove the package manager’s fledgling 
 ability to treat certain dependencies as test-only. This has led to a 
 myriad of clever-but-needlessly-complex workarounds ([1], [2], [3]) on the 
 part of 3rd parties to recover the feature themselves. In addition, the 
 Swift community has come up with a number of their own frameworks to 
 augment functionality in XCTest but depending on these external testing 
 frameworks is brittle and difficult to get right.
 
 Proposed solution
 
 We propose the re-introduction of the testDependencies parameter in 
 Package Manifests to support external test-only dependencies. To support 
 local test-only targets we also propose the introduction of the 
 testTargets parameter and an extension of the existing swift test command 
 to support individual invocation of these targets.
 
 Detailed design
 
 The behavior of the new testDependencies parameter mirrors that of the 
 existing dependencies parameter with one important difference: fetched 
 dependencies are only built to support package-defined test targets as 
 part of an invocation of swift test.
 
 import PackageDescription
 
 let package = Package(
 name: "Foo",
 targets: [
 Target(name: "Foo")
 ],
 dependencies: [
 .Package(url: "https://github.com/org/ana.git;, versions: 
 Version(1,0,0)...Version(1,9,9)),
 ],
 testDependencies: [
 .Package(url: "https://github.com/org/anism.git;, versions: 
 Version(1,0,0)...Version(1,9,9)),
 ]
 )
 Similarly, the behavior of the testTargets field mirrors that of the 
 existing targets field but defines a set of targets that are only built 
 during an invocation of swift test. Importantly, a target defined in 
 testTargets may reference a target defined in targets but not vice-versa. 
 Should that behavior be needed, the test target should be promoted to a 
 “full” target.
 
 import PackageDescription
 
 let package = Package(
 name: "SwiftPM",
 targets: [
 Target(
 name: "PackageDescription",
 dependencies: []),
 
 // MARK: Support libraries
 
 Target(
 /** Cross-platform access to bare `libc` functionality. */
 name: "libc",
 dependencies: []),
 Target(
 /** “Swifty” POSIX functions from libc */
 name: "POSIX",
 dependencies: ["libc"]),
 Target(
 /** Basic

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Jonathan Hull via swift-evolution 
+1  Best so far.

> On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
> Freak Show wrote:
> 
>> Am I the only one who finds this incredibly ugly and hard to read?
>> 
>> This is more or less solved by inject:into: idiom.  There is no reason for 
>> inout for this particular problem.
> 
> Yeah, the original signature seems more useful. If you go all `inout` like 
> Gwendal suggested, you might as well just iterate over the sequence with `for 
> x in xs`, updating the state as you go.
> 
> But your comment brought another idea to mind: if `mutating:` is considered a 
> bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
> similar to what Karl suggested earlier in this thread?
> 
> I think it reads very well at the call site, does not suggest `inout`ness of 
> the argument too much (of course there's no `&` at the call site either), and 
> it's still easily found with auto-completion:
> 
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }
> 
> — Pyry
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Review] SE-0150 Package Manager Support for branches

2017-01-24 Thread David Hart via swift-evolution 


> On 24 Jan 2017, at 19:18, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0150 “ Package Manager Support for branches" begins now and 
> runs through January 31, 2017. The proposal is available here:
> 
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>  https://lists.swift.org/mailman/listinfo/swift-build-dev
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
> 
> 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?

This is going to be immensely useful. I remember depending on many `swift3` 
branches during the summer on my current iOS dependency manager of choice. Also 
applies for bug fix branches, experimental feature branches, etc...

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

Yes. Very significant.

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

Yes.

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

All other dependent managers I've used had this feature and I'v ended up using 
it fairly often.

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

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

2017-01-24 Thread David Hart via swift-evolution 

>   • What is your evaluation of the proposal?

It's a small improvement which will be very useful for a certain class of 
people/projects. I see no downsides.

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

Not significant for me, but quick enough to implement to be worth it I guess.

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

Yes.

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

SwiftPM already goes much further in terms of package development (with edit) 
than most other dependency managers for iOS. ++

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

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

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

2017-01-24 Thread thislooksfun via swift-evolution 
No problem, it's been inactive for a couple weeks since I've been really busy. 
And yeah, yours is more thorough. I didn't even consider adding a `testTargets` 
section. That alone is worth merging.

-thislooksfun (tlf)

> On Jan 24, 2017, at 11:55 PM, Robert Widmann  wrote:
> 
> Oh, I'm sorry.  I didn't know there was existing work in this space.  
> Considering this proposal looks like it expands on your earlier work, would 
> you like to sign on to this and merge the two efforts?
> 
> ~Robert Widmann
> 
> 2017/01/25 0:47、thislooksfun  > のメッセージ:
> 
>> As the author of the Add support for test-only dependencies 
>> 
>>  thread, and the accompanying draft 
>> ,
>>  this gets a big +1 from me.
>> 
>> -thislooksfun (tlf)
>> 
>>> On Jan 24, 2017, at 4:32 PM, Robert Widmann via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift Community,
>>> 
>>> Harlan Haskins and I have been working on libraries 
>>>  to make interacting with LLVM and Clang’s 
>>> APIs more elegant with native Swift interfaces.  While writing up the 
>>> packages we realized the package manager wouldn’t allow us to specify 
>>> testing targets and test-only dependencies.  To rectify that, I have 
>>> attached a draft proposal for adding test-only targets and dependency 
>>> fields to the Swift Package manager.  This proposal can also be read in 
>>> gist form .
>>> 
>>> Cheers,
>>> 
>>> ~Robert Widmann
>>> 
>>> Test-Only Package Dependencies and Targets
>>> 
>>> Proposal: SE- 
>>> Authors: Harlan Haskins , Robert Widmann 
>>> 
>>> Review Manager: TBD
>>> Status: Awaiting review
>>>  
>>> Introduction
>>> 
>>> This proposal reinstates Swift package manager’s ability to fetch 
>>> dependencies and build targets scoped exclusively to the testing module(s) 
>>> of a given package.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal 
>>> 
>>>  
>>> Motivation
>>> 
>>> Soon after SE-0019 
>>> 
>>>  identified the need for richer test-only dependencies and targets, a 
>>> decision was made to remove the package manager’s fledgling ability to 
>>> treat certain dependencies as test-only. This has led to a myriad of 
>>> clever-but-needlessly-complex workarounds ([1] 
>>> ,
>>>  [2] , 
>>> [3] ) on 
>>> the part of 3rd parties to recover the feature themselves. In addition, the 
>>> Swift community has come up with a number of their own frameworks to 
>>> augment functionality in XCTest but depending on these external testing 
>>> frameworks is brittle and difficult to get right.
>>> 
>>>  
>>> Proposed
>>>  solution
>>> 
>>> We propose the re-introduction of the testDependencies parameter in Package 
>>> Manifests to support external test-only dependencies. To support local 
>>> test-only targets we also propose the introduction of the testTargets 
>>> parameter and an extension of the existing swift test command to support 
>>> individual invocation of these targets.
>>> 
>>>  
>>> Detailed
>>>  design
>>> 
>>> The behavior of the new testDependencies parameter mirrors that of the 
>>> existing dependencies parameter with one important difference: fetched 
>>> dependencies are only built to support package-defined test targets as part 
>>> of an invocation of swift test.
>>> 
>>> import PackageDescription
>>> 
>>> let package = Package(
>>> name: "Foo",
>>> targets: [
>>> Target(name: "Foo")
>>> ],
>>> dependencies: [
>>> .Package(url: "https://github.com/org/ana.git 
>>> ", versions: 
>>> Version(1,0,0)...Version(1,9,9)),
>>> ],
>>> testDependencies: [
>>> .Package(url: "https://github.com/org/anism.git 
>>> ", versions: 
>>> Version(1,0,0)...Version(1,9,9)),
>>> ]
>>> )
>>> Similarly, the behavior of the

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

2017-01-24 Thread Russ Bishop via swift-evolution 

> 
>> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0149 “ Package Manager Support for Top of Tree development" 
>> begins now and runs through January 31, 2017. The proposal is available here:
>> 
>> What is your evaluation of the proposal?
+1.

This seems reasonable and not terribly controversial to me.

Russ

>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> - Daniel
>> 
>> Review Manager
>> 
>> ___
>> swift-build-dev mailing list
>> swift-build-...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
> 
> ___
> 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] Test-Only Package Dependencies and Targets

2017-01-24 Thread Russ Bishop via swift-evolution 
I never agreed with removing it so this gets a bit fat +1 from me.

Russ


> On Jan 24, 2017, at 2:32 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hello Swift Community,
> 
> Harlan Haskins and I have been working on libraries 
>  to make interacting with LLVM and Clang’s 
> APIs more elegant with native Swift interfaces.  While writing up the 
> packages we realized the package manager wouldn’t allow us to specify testing 
> targets and test-only dependencies.  To rectify that, I have attached a draft 
> proposal for adding test-only targets and dependency fields to the Swift 
> Package manager.  This proposal can also be read in gist form 
> .
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Test-Only Package Dependencies and Targets
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal reinstates Swift package manager’s ability to fetch 
> dependencies and build targets scoped exclusively to the testing module(s) of 
> a given package.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Soon after SE-0019 
> 
>  identified the need for richer test-only dependencies and targets, a 
> decision was made to remove the package manager’s fledgling ability to treat 
> certain dependencies as test-only. This has led to a myriad of 
> clever-but-needlessly-complex workarounds ([1] 
> , 
> [2] , [3] 
> ) on the part 
> of 3rd parties to recover the feature themselves. In addition, the Swift 
> community has come up with a number of their own frameworks to augment 
> functionality in XCTest but depending on these external testing frameworks is 
> brittle and difficult to get right.
> 
>  
> Proposed
>  solution
> 
> We propose the re-introduction of the testDependencies parameter in Package 
> Manifests to support external test-only dependencies. To support local 
> test-only targets we also propose the introduction of the testTargets 
> parameter and an extension of the existing swift test command to support 
> individual invocation of these targets.
> 
>  
> Detailed
>  design
> 
> The behavior of the new testDependencies parameter mirrors that of the 
> existing dependencies parameter with one important difference: fetched 
> dependencies are only built to support package-defined test targets as part 
> of an invocation of swift test.
> 
> import PackageDescription
> 
> let package = Package(
> name: "Foo",
> targets: [
> Target(name: "Foo")
> ],
> dependencies: [
> .Package(url: "https://github.com/org/ana.git 
> ", versions: Version(1,0,0)...Version(1,9,9)),
> ],
> testDependencies: [
> .Package(url: "https://github.com/org/anism.git 
> ", versions: 
> Version(1,0,0)...Version(1,9,9)),
> ]
> )
> Similarly, the behavior of the testTargets field mirrors that of the existing 
> targets field but defines a set of targets that are only built during an 
> invocation of swift test. Importantly, a target defined in testTargets may 
> reference a target defined in targets but not vice-versa. Should that 
> behavior be needed, the test target should be promoted to a “full” target.
> 
> import PackageDescription
> 
> let package = Package(
> name: "SwiftPM",
> targets: [
> Target(
> name: "PackageDescription",
> dependencies: []),
> 
> // MARK: Support libraries
> 
> Target(
> /** Cross-platform access to bare `libc` functionality. */
> name: "libc",
> dependencies: []),
> Target(
> /** “Swifty” POSIX functions from libc */
> name: "POSIX",
> dependencies: ["libc"]),
> Target(
> /** Basic support library */
> name: "Basic",
> dependencies: ["libc", "POSIX"]),
> 
> /* Omitted for Brevity */
>  ],
>  testTargets: [
> Target(
> name:

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

2017-01-24 Thread Robert Widmann via swift-evolution 
Oh, I'm sorry.  I didn't know there was existing work in this space.  
Considering this proposal looks like it expands on your earlier work, would you 
like to sign on to this and merge the two efforts?

~Robert Widmann

2017/01/25 0:47、thislooksfun  のメッセージ:

> As the author of the Add support for test-only dependencies thread, and the 
> accompanying draft, this gets a big +1 from me.
> 
> -thislooksfun (tlf)
> 
>> On Jan 24, 2017, at 4:32 PM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> Hello Swift Community,
>> 
>> Harlan Haskins and I have been working on libraries to make interacting with 
>> LLVM and Clang’s APIs more elegant with native Swift interfaces.  While 
>> writing up the packages we realized the package manager wouldn’t allow us to 
>> specify testing targets and test-only dependencies.  To rectify that, I have 
>> attached a draft proposal for adding test-only targets and dependency fields 
>> to the Swift Package manager.  This proposal can also be read in gist form.
>> 
>> Cheers,
>> 
>> ~Robert Widmann
>> 
>> Test-Only Package Dependencies and Targets
>> Proposal: SE-
>> Authors: Harlan Haskins, Robert Widmann
>> Review Manager: TBD
>> Status: Awaiting review
>> Introduction
>> 
>> This proposal reinstates Swift package manager’s ability to fetch 
>> dependencies and build targets scoped exclusively to the testing module(s) 
>> of a given package.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal
>> 
>> Motivation
>> 
>> Soon after SE-0019 identified the need for richer test-only dependencies and 
>> targets, a decision was made to remove the package manager’s fledgling 
>> ability to treat certain dependencies as test-only. This has led to a myriad 
>> of clever-but-needlessly-complex workarounds ([1], [2], [3]) on the part of 
>> 3rd parties to recover the feature themselves. In addition, the Swift 
>> community has come up with a number of their own frameworks to augment 
>> functionality in XCTest but depending on these external testing frameworks 
>> is brittle and difficult to get right.
>> 
>> Proposed solution
>> 
>> We propose the re-introduction of the testDependencies parameter in Package 
>> Manifests to support external test-only dependencies. To support local 
>> test-only targets we also propose the introduction of the testTargets 
>> parameter and an extension of the existing swift test command to support 
>> individual invocation of these targets.
>> 
>> Detailed design
>> 
>> The behavior of the new testDependencies parameter mirrors that of the 
>> existing dependencies parameter with one important difference: fetched 
>> dependencies are only built to support package-defined test targets as part 
>> of an invocation of swift test.
>> 
>> import PackageDescription
>> 
>> let package = Package(
>> name: "Foo",
>> targets: [
>> Target(name: "Foo")
>> ],
>> dependencies: [
>> .Package(url: "https://github.com/org/ana.git;, versions: 
>> Version(1,0,0)...Version(1,9,9)),
>> ],
>> testDependencies: [
>> .Package(url: "https://github.com/org/anism.git;, versions: 
>> Version(1,0,0)...Version(1,9,9)),
>> ]
>> )
>> Similarly, the behavior of the testTargets field mirrors that of the 
>> existing targets field but defines a set of targets that are only built 
>> during an invocation of swift test. Importantly, a target defined in 
>> testTargets may reference a target defined in targets but not vice-versa. 
>> Should that behavior be needed, the test target should be promoted to a 
>> “full” target.
>> 
>> import PackageDescription
>> 
>> let package = Package(
>> name: "SwiftPM",
>> targets: [
>> Target(
>> name: "PackageDescription",
>> dependencies: []),
>> 
>> // MARK: Support libraries
>> 
>> Target(
>> /** Cross-platform access to bare `libc` functionality. */
>> name: "libc",
>> dependencies: []),
>> Target(
>> /** “Swifty” POSIX functions from libc */
>> name: "POSIX",
>> dependencies: ["libc"]),
>> Target(
>> /** Basic support library */
>> name: "Basic",
>> dependencies: ["libc", "POSIX"]),
>> 
>> /* Omitted for Brevity */
>>  ],
>>  testTargets: [
>> Target(
>> name: "BasicPerformanceTests",
>> dependencies: ["Basic"]),
>>/* Omitted for Brevity */
>>  ]
>>  )
>> Finally, with well-defined test targets in hand, we propose swift test be 
>> amended to support individual test execution.
>> 
>> We propose the following syntax to execute all tests of all known test 
>> targets.
>> 
>> $ swift test
>> To run a set of specific test cases, reference the module-defining test 
>> target and the specific name of a subclass of XCTestCase:
>> 
>> $ swift test TestModule.TestCase
>> To run an individual

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

2017-01-24 Thread thislooksfun via swift-evolution 
As the author of the Add support for test-only dependencies 

 thread, and the accompanying draft 
,
 this gets a big +1 from me.

-thislooksfun (tlf)

> On Jan 24, 2017, at 4:32 PM, Robert Widmann via swift-evolution 
>  wrote:
> 
> Hello Swift Community,
> 
> Harlan Haskins and I have been working on libraries 
>  to make interacting with LLVM and Clang’s 
> APIs more elegant with native Swift interfaces.  While writing up the 
> packages we realized the package manager wouldn’t allow us to specify testing 
> targets and test-only dependencies.  To rectify that, I have attached a draft 
> proposal for adding test-only targets and dependency fields to the Swift 
> Package manager.  This proposal can also be read in gist form 
> .
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Test-Only Package Dependencies and Targets
> 
> Proposal: SE- 
> Authors: Harlan Haskins , Robert Widmann 
> 
> Review Manager: TBD
> Status: Awaiting review
>  
> Introduction
> 
> This proposal reinstates Swift package manager’s ability to fetch 
> dependencies and build targets scoped exclusively to the testing module(s) of 
> a given package.
> 
> Swift-evolution thread: Discussion thread topic for that proposal 
> 
>  
> Motivation
> 
> Soon after SE-0019 
> 
>  identified the need for richer test-only dependencies and targets, a 
> decision was made to remove the package manager’s fledgling ability to treat 
> certain dependencies as test-only. This has led to a myriad of 
> clever-but-needlessly-complex workarounds ([1] 
> , 
> [2] , [3] 
> ) on the part 
> of 3rd parties to recover the feature themselves. In addition, the Swift 
> community has come up with a number of their own frameworks to augment 
> functionality in XCTest but depending on these external testing frameworks is 
> brittle and difficult to get right.
> 
>  
> Proposed
>  solution
> 
> We propose the re-introduction of the testDependencies parameter in Package 
> Manifests to support external test-only dependencies. To support local 
> test-only targets we also propose the introduction of the testTargets 
> parameter and an extension of the existing swift test command to support 
> individual invocation of these targets.
> 
>  
> Detailed
>  design
> 
> The behavior of the new testDependencies parameter mirrors that of the 
> existing dependencies parameter with one important difference: fetched 
> dependencies are only built to support package-defined test targets as part 
> of an invocation of swift test.
> 
> import PackageDescription
> 
> let package = Package(
> name: "Foo",
> targets: [
> Target(name: "Foo")
> ],
> dependencies: [
> .Package(url: "https://github.com/org/ana.git 
> ", versions: Version(1,0,0)...Version(1,9,9)),
> ],
> testDependencies: [
> .Package(url: "https://github.com/org/anism.git 
> ", versions: 
> Version(1,0,0)...Version(1,9,9)),
> ]
> )
> Similarly, the behavior of the testTargets field mirrors that of the existing 
> targets field but defines a set of targets that are only built during an 
> invocation of swift test. Importantly, a target defined in testTargets may 
> reference a target defined in targets but not vice-versa. Should that 
> behavior be needed, the test target should be promoted to a “full” target.
> 
> import PackageDescription
> 
> let package = Package(
> name: "SwiftPM",
> targets: [
> Target(
> name: "PackageDescription",
> dependencies: []),
> 
> // MARK: Support libraries
> 
> Target(
> /** Cross-platform access to bare `libc` functionality. */
> name: "libc",
> dependencies: []),
> Target(
> /** “Swifty” POSIX functions from libc */
> name: "POSIX",
> dependencies: ["libc"]),
>

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Zach Waldowski via swift-evolution 
I'll use Karl's point here as a minor jumping-off point for a semi-
related train of thought… I'm excited by the content of the original
manifesto, including a powerful Unicode  namespace and types. But as
I've continued down the thread, I've had growing concern about  modeling
strings breadthwise in the type system i.e., with UTF8String and so on.


I strongly want Swift to have world-class string processing, but I
believe even more strongly in the language's spirit of progressive
disclosure. Newcomers to Swift's current String API find it difficult
(something I personally disagree with, but that's neither here nor
there); I don't think that difficulty is solved by aggressively use-
specific type modeling. I instead think it gives rise to the same severe
cargo-culting that gets us the scarily prevalent
String.Index.init(offset:) extensions in the current model.


Best

  Zach Waldowski

  z...@waldowski.me



On Tue, Jan 24, 2017, at 10:15 PM, Karl Wagner via swift-evolution wrote:
> 

>> 

>>> I hope I am correct about the no-copy thing, and I would also
>>> like to
>>> permit promoting C strings to Swift strings without
>>> validation.  This
>>> is obviously unsafe in general, but I know my strings... and I care
>>> about performance. ;)

>> 

>> We intend to support that use-case.  That's part of the reason
>> for the
>> ValidUTF8 and ValidUTF16 encodings you see here:

>> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L598
>> and here:

>> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L862
> 

> It seems a little strange to me that a pre-validated UTF8 string from
> C would have different types to a UTF8String (i.e. using ValidUTF8 vs
> UTF8). It defeats the point of having the encoding represented in the
> type-system.
> 

> For example, if I write a generic function:

> 

>> func sendMessage(from:
>> Source)
> 

> I would only be able to accept UTF-8 text which hasn’t already been
> validated.
> 

> What about if we allowed each encoding to provide multiple kinds of
> decoder? That would also allow us to substitute our own decoders in,
> if there are application-specific shortcuts we can take.
> 

>> protocol UnicodeEncoding {

>>   associatedtype CodeUnit

>> 

>>   associatedtype ValidatingDecoder: UnicodeDecoder

>>   associatedtype NonValidatingDecoder: UnicodeDecoder
>> }

>> 

>> protocol UnicodeDecoder {

>> associatedtype Encoding: UnicodeEncoding

>> associatedtype DecodedScalar: RandomAccessCollection where
>> Iterator.Element == Encoding.CodeUnit
>> 

>> static func parse1Forward(…) -> ParseResult> C.Index>
>> static func parse1Backward(…) -> ParseResult> C.Index>
>> }

>> // Not shown: UnicodeEncoder protocol, with transcodeScalar
>> function.
>> 

>> struct UTF8: UnicodeEncoding  { 

>> typealias CodeUnit = UInt8  

>> typealias ValidatingDecoder= ValidatingUTF8Decoder

>> typealias NonValidatingDecoder = NonValidatingUTF8Decoder

>> }

>> 

>> struct NonValidatingUTF8Decoder: UnicodeDecoder {

>> typealias Encoding = UTF8

>> struct DecodedScalar: RandomAccessCollection { … }

>> // Parsing functions

>> }

>> 

>> struct ValidatingUTF8Decoder: UnicodeDecoder {

>> typealias Encoding = UTF8

>> typealias DecodedScalar = NonValidatingUTF8Decoder.DecodedScalar
>> // newtype would be cool here
>> // Parsing functions

>> }

>> 

>> struct String {

>> init(from: C, encodedAs: Encoding, using:
>> Decoder = Encoding.ValidatingDecoder)
>> where C: Collection, C.Iterator.Element == Encoding.CodeUnit,
>> Decoder.Encoding == Encoding {
>> 

>>  // transcode to native String encoding using ‘Decoder’ we
>>  were given
>> }

>> }

> 

> - Karl

> _

> swift-evolution mailing list

> swift-evolution@swift.org

> https://lists.swift.org/mailman/listinfo/swift-evolution


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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Brent Royal-Gordon via swift-evolution 
> On Jan 24, 2017, at 11:22 AM, Dave Abrahams via swift-evolution 
>  wrote:
>> 
>> How important is that, though? If you're using a `Substring`, you
>> expect to keep the top-level `String` around and probably continue
>> sharing storage with it, so you're probably extending its lifetime
>> anyway. Or are you thinking of this as a speed optimization, rather
>> than a memory optimization?
> 
> It's both.  It's true that it will rarely save space, but sometimes it
> will.  More importantly perhaps, it eliminates ARC traffic.

I'll probably reply to more of this later, but I had a random shower thought I 
wanted to share:

Could we build this capability into `Slice` so that any collection (or at least 
any collection which conforms to the right, probably stdlib-internal, protocol) 
could pack data directly into the instance instead of holding a reference to 
the base collection? Obviously only collections holding trivial types could do 
it, but I could see that being a useful general optimization.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Xiaodi Wu via swift-evolution 
Hmm, good point--none come to mind.


On Tue, Jan 24, 2017 at 14:03 Matthew Johnson 
wrote:

On Jan 24, 2017, at 1:27 PM, Xiaodi Wu  wrote:

Hmm, brainstorming here. Given the pervasive use of `with` to mean "this
isn't accessible otherwise but inside this closure it's $0", maybe
`reduce(with: 42) { $0 += 1 }` might give a useful hint?


Are there any current uses of `with` passed `inout`?

On Tue, Jan 24, 2017 at 13:19 Matthew Johnson 
wrote:

On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:

Hmm, it reads well, but IMO it avoids being misleading only because it
doesn't mean anything. In what way are you reducing "into" the first
argument any more so than the classic reduce function?


It isn't perfect, but it’s better than the alternatives I’ve seen so far.

In the classic reduce function a new value is produced for each step of the
reduction.  In this variation, each step reduces “into” an accumulator that
is initialized with the seed value.  In that sense, you could say that you
reduce “into” the seed value.

Labeling the argument `into` is a little bit of a stretch but I think it's
far superior to `mutating` which is pretty misleading at the call site.  I
think it would be pretty hard to come up with something better, but let’s
keep the bikeshed going if anyone has additional ideas.


On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution <
swift-evolution@swift.org> wrote:


Freak Show wrote:

Am I the only one who finds this incredibly ugly and hard to read?

This is more or less solved by inject:into: idiom.  There is no reason for
inout for this particular problem.


Yeah, the original signature seems more useful. If you go all `inout` like
Gwendal suggested, you might as well just iterate over the sequence with
`for x in xs`, updating the state as you go.

But your comment brought another idea to mind: if `mutating:` is considered
a bad name for a non-`inout` argument, how about `*reduce(into:combine:)`*,
similar to what Karl suggested earlier in this thread?

I think it reads very well at the call site, does not suggest `inout`ness
of the argument too much (of course there's no `&` at the call site
either), and it's still easily found with auto-completion:

let counts = words.reduce(into: [:]) {
  $0[$1] = ($0[$1] ?? 0) + 1
}


+1.  This is concise and I think it captures the essence of what is
happening pretty well!

The third variation where the seed argument actually *is* `inout` might
also be interesting in some cases where you *already* have a `var` that you
want to accumulate into.  I believe I have done this in the past in my own
code but don’t have an example handy.


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

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Karl Wagner via swift-evolution 

> 
>> I hope I am correct about the no-copy thing, and I would also like to
>> permit promoting C strings to Swift strings without validation.  This
>> is obviously unsafe in general, but I know my strings... and I care
>> about performance. ;)
> 
> We intend to support that use-case.  That's part of the reason for the
> ValidUTF8 and ValidUTF16 encodings you see here:
> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L598
>  
> 
> and here:
> https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L862
>  
> 

It seems a little strange to me that a pre-validated UTF8 string from C would 
have different types to a UTF8String (i.e. using ValidUTF8 vs UTF8). It defeats 
the point of having the encoding represented in the type-system.

For example, if I write a generic function:

func sendMessage(from: Source)

I would only be able to accept UTF-8 text which hasn’t already been validated. 

What about if we allowed each encoding to provide multiple kinds of decoder? 
That would also allow us to substitute our own decoders in, if there are 
application-specific shortcuts we can take.

protocol UnicodeEncoding {
  associatedtype CodeUnit

  associatedtype ValidatingDecoder: UnicodeDecoder
  associatedtype NonValidatingDecoder: UnicodeDecoder
}

protocol UnicodeDecoder {
associatedtype Encoding: UnicodeEncoding
associatedtype DecodedScalar: RandomAccessCollection where Iterator.Element 
== Encoding.CodeUnit

static func parse1Forward(…) -> ParseResult
static func parse1Backward(…) -> ParseResult
}
// Not shown: UnicodeEncoder protocol, with transcodeScalar function.

struct UTF8: UnicodeEncoding  { 
typealias CodeUnit = UInt8  
typealias ValidatingDecoder= ValidatingUTF8Decoder
typealias NonValidatingDecoder = NonValidatingUTF8Decoder
}

struct NonValidatingUTF8Decoder: UnicodeDecoder {
typealias Encoding = UTF8
struct DecodedScalar: RandomAccessCollection { … }
// Parsing functions
}

struct ValidatingUTF8Decoder: UnicodeDecoder {
typealias Encoding = UTF8
typealias DecodedScalar = NonValidatingUTF8Decoder.DecodedScalar // newtype 
would be cool here
// Parsing functions
}

struct String {
init(from: C, encodedAs: Encoding, using: Decoder = 
Encoding.ValidatingDecoder) 
where C: Collection, C.Iterator.Element == Encoding.CodeUnit, 
Decoder.Encoding == Encoding {

 // transcode to native String encoding using ‘Decoder’ we were given
}
}

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Xiaodi Wu via swift-evolution 
No code would be broken. Like functions, case `bar(a:)` can be referred to
as `bar` as long as there is no ambiguity. No existing code can have more
than one case named bar.
On Tue, Jan 24, 2017 at 19:17 Christopher Kornher  wrote:

> Sorry for not connecting the dots…yet another example of why we need a
> better way to handle long discussions :)
> …and the dangers of multitasking, perhaps…
>
> I guess that this shows that having multiple cases with the same name,
> distinguished by the type of associated value, is possible without this
> proposal, for whatever that may be worth.
>
> It is anecdotal, perhaps, but this proposal will break a lot of my code. I
> tend to use labels as public names for associated values, and different
> internal names. Forcing consistent naming is sensible. It would come at the
> cost of breaking a significant amount of existing code and making the
> language more “fiddly”.
>
> Comparisons have been made to function signatures, but enums cases with >
> 2 values are rare in my experience, and functions can often have  > 2
> arguments. Perhaps enums with more associated values will become more
> common if enum cases become more like structure declarations with well
> defined element names.
>
> Just a random thought: Treating enum cases like structs would become more
> reasonable as a result of this proposal i.e. they could conform to
> protocols. I am not sure that anyone wants to worry about functions for
> enum cases, but it might be useful to pass enum cases directly to functions
> that would normally need a struct. Unifying enums and structs in this way
> might an interesting thing to consider.
>
> Associated values that can differ for each enum case seems to be a feature
> unique to Swift. Is this a feature of any other language?
>
> On Jan 24, 2017, at 4:55 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Yes, but *this* proposal is precisely to make the label part of the name.
>
>
> On Tue, Jan 24, 2017 at 17:51 Christopher Kornher  wrote:
>
> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm now confused who is arguing for what. Enums cases cannot have the same
> name. As far as I'm aware, this proposal does not seek to change that. Each
> case must still be unique. It only changes whether labels are regarded as
> part of the name or part of the associated type.
>
>
> Labels are currently neither part of the name nor part of the associated
> type. See my example (it runs in the playground in Xcode 8.2.1).
>
> Forgive any lack of precise terminology:  Labels for enums with associated
> values are currently only used to create a "function signature" for
> constructing values for the enum. They are ignored in all other uses of the
> enum AFAIK.
>
> My proposal is a way to allow multiple cases with the same name without
> breaking existing code. It has the benefit of giving enums a richer
> meaning, in simple English:
>
> Here is an example of a way to handle this currently and what it would
> become:
>
> // Runs now
> enum MultipleTypes {
> case anInt( value: Int )
> case aString( value: String )
> }
>
> enum E {
> case a( a: MultipleTypes )
> }
>
> let theCurrentWay = E.a( a: .aString( value: "str") )
>
> switch theCurrentWay {
> case .a( let x ) :
> switch x {
> case .anInt( let x ) :
> break
>
> case .aString( let x ) :
> break
> }
> }
>
> // Proposed:
>
> /*
> enum theNewWay {
>  case a( value: Int ) :
>  case a( value: String ) :
> }
>
> switch theCurrentWay {
> case .a( let x: Int ) :
> break
>
> case .a( let x: String ) :
> break
> }
> */
>
>
>
>
> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 24, 2017, at 4:02 PM, Daniel Duan  wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that  this rule would be consistent with the handing of Swift
> function signatures, but my proposal is self-consistent and:
>
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed and
> in past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently legal
> but would not be if the enum case “name” is the entire signature for
> constructing it:
>
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
>
> let anEmum = E.a( a: 4 )
>
>
> switch anEmum {
> case .a( let x ) :
> break
> case .b( let x ) :
> break
> }
>
> switch anEmum {
> case .a( let y )

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Félix Cloutier via swift-evolution 

> Le 24 janv. 2017 à 11:33, Dave Abrahams via swift-evolution 
>  a écrit :
 I've never seen anyone start a string with a combining character on 
 purpose, 
>>> 
>>> It will occur as a byproduct of the process of attaching a diacritic
>>> to a base character.
>> 
>> Unless you're in the business of writing a text editor, I don't know
>> if that's a common use case.
> 
> I don't either, to be honest.  But the experts I consult with keep
> reassuring me that it's an important one.

Would it be possible that the Unicode experts' use cases are different from 
non-experts' use cases? It would make sense to put people who know a lot about 
Unicode in charge of handling complex Unicode operations, and that makes that 
use case very important to them, but through their hard work no one else needs 
to care about it.

 though I'm familiar with just one natural language that needs
 combining characters. I can imagine that it could be a convenient
 feature in other natural languages.
 
 However, if Swift Strings are now designed for machine processing
 and less for human language convenience, for me, it's easy enough to
 justify a safe default in the context of machine processing: `a+b`
 will not combine the end of `a` with the start of `b`. You could do
 this by inserting a ◌ that `b` could combine with if necessary.
>>> 
>>> You can do it, but it trades one semantic problem for a usability
>>> problem, without solving all the semantic problems: you end up with
>>> a.count + b.count == (a+b).count, sure, but you still don't satisfy
>>> the usual law of collections that (a+b).contains(b.first!) if b is
>>> non-empty, and now you've made it difficult to attach diacritics to
>>> base characters.
>> 
>> "Difficult".
>> 
>> What kind of processing would you suggest on a variable "b" in the
>> expression "\(a),\(b)" to ensure that the result can be split with a
>> comma?
> 
> I'm sorry, I don't understand what you're driving at, here.

Okay, so I'm serializing two strings "a" and "b", and later on I want to 
deserialize them. I control "a", and the user controls "b". I know that I'll 
never have a comma in "a", so one obvious way to serialize the two strings is 
with "\(a),\(b)", and the most obvious way to deserialize them is with 
string.split(maxSplits: 2) { $0 == "," }.

For the example, string "a" is "hello", and the user put in "\u{0301}screw you" 
for "b". This makes the result "hello,́screw you". Now split misses the comma.

How do I fix it?

Félix

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Ben Rimmington via swift-evolution 


> In practice, these semantics will usually be tied to the version of the 
> installed ICU library, which programmatically encodes the most complex rules 
> of the Unicode Standard and its de-facto extension, CLDR.

Unicode is released in June. 

CLDR is released in March and September. 

ICU is released in April and October.

Therefore "libicucore" on Apple platforms will always use an older Unicode 
standard.
For example, iOS 10 and macOS Sierra are using ICU 57, which doesn't support 
Unicode 9.

Could you include the latest ICU alongside the Swift standard library?

-- Ben

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Matt Whiteside via swift-evolution 

> On Jan 22, 2017, at 15:40, Chris Lattner via swift-evolution 
>  wrote:
> Right, the only sensible semantics for a one sided range with an open end 
> point is that it goes to the end of the collection.  I see a few different 
> potential colors to paint this bikeshed with, all of which would have the 
> semantics “c[i.. 
> 1) Provide "c[i...]":
> 2) Provide "c[i..<]":
> 3) Provide both "c[i..<]” and "c[i…]":
> 
> Since all of these operations would have the same behavior, it comes down to 
> subjective questions:
> 
> a) Do we want redundancy?  IMO, no, which is why #3 is not very desirable.
> b) Which is easier to explain to people?  As you say, "i..< is shorthand for 
> i.. c) Which is subjectively nicer looking?  IMO, #1 is much nicer 
> typographically.  The ..< formulation looks like symbol soup, particularly 
> because most folks would not put a space before ].
> 
> There is no obvious winner, but to me, I tend to prefer #1.  What do other 
> folks think?

I also prefer #1.  It’s a shame that this conflicts with the potential syntax 
for variadic generics.  Is there really no way around this?  I’m showing my 
ignorance on compilers here, but couldn’t the fact that variadic generics will 
be inside angle brackets be used to distinguish?

-Matt




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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Christopher Kornher via swift-evolution 
Sorry for not connecting the dots…yet another example of why we need a better 
way to handle long discussions :)
…and the dangers of multitasking, perhaps…

I guess that this shows that having multiple cases with the same name, 
distinguished by the type of associated value, is possible without this 
proposal, for whatever that may be worth.

It is anecdotal, perhaps, but this proposal will break a lot of my code. I tend 
to use labels as public names for associated values, and different internal 
names. Forcing consistent naming is sensible. It would come at the cost of 
breaking a significant amount of existing code and making the language more 
“fiddly”.

Comparisons have been made to function signatures, but enums cases with > 2 
values are rare in my experience, and functions can often have  > 2 arguments. 
Perhaps enums with more associated values will become more common if enum cases 
become more like structure declarations with well defined element names.

Just a random thought: Treating enum cases like structs would become more 
reasonable as a result of this proposal i.e. they could conform to protocols. I 
am not sure that anyone wants to worry about functions for enum cases, but it 
might be useful to pass enum cases directly to functions that would normally 
need a struct. Unifying enums and structs in this way might an interesting 
thing to consider. 

Associated values that can differ for each enum case seems to be a feature 
unique to Swift. Is this a feature of any other language?

> On Jan 24, 2017, at 4:55 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Yes, but *this* proposal is precisely to make the label part of the name.
> 
> 
> On Tue, Jan 24, 2017 at 17:51 Christopher Kornher  > wrote:
>> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I'm now confused who is arguing for what. Enums cases cannot have the same 
>> name. As far as I'm aware, this proposal does not seek to change that. Each 
>> case must still be unique. It only changes whether labels are regarded as 
>> part of the name or part of the associated type.
> 
> Labels are currently neither part of the name nor part of the associated 
> type. See my example (it runs in the playground in Xcode 8.2.1).
> 
> Forgive any lack of precise terminology:  Labels for enums with associated 
> values are currently only used to create a "function signature" for 
> constructing values for the enum. They are ignored in all other uses of the 
> enum AFAIK.
> 
> My proposal is a way to allow multiple cases with the same name without 
> breaking existing code. It has the benefit of giving enums a richer meaning, 
> in simple English:
> 
> Here is an example of a way to handle this currently and what it would become:
> 
> // Runs now
> enum MultipleTypes {
> case anInt( value: Int )
> case aString( value: String )
> }
> 
> enum E {
> case a( a: MultipleTypes )
> }
> 
> let theCurrentWay = E.a( a: .aString( value: "str") )
> 
> switch theCurrentWay {
> case .a( let x ) :
> switch x {
> case .anInt( let x ) :
> break
> 
> case .aString( let x ) :
> break
> }
> }
> 
> // Proposed:
> 
> /*
> enum theNewWay {
>  case a( value: Int ) :
>  case a( value: String ) :
> }
> 
> switch theCurrentWay {
> case .a( let x: Int ) :
> break
> 
> case .a( let x: String ) :
> break
> }
> */
> 
> 
>> 
>> 
>> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution 
>> > wrote:
>>> On Jan 24, 2017, at 4:02 PM, Daniel Duan >> > wrote:
>>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
 
 
 Daniel Duan
 Sent from my iPhone
 
 On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
 > wrote:
 
> I agree that  this rule would be consistent with the handing of Swift 
> function signatures, but my proposal is self-consistent and:
> 
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed 
> and in past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently 
> legal but would not be if the enum case “name” is the entire signature 
> for constructing it:
> 
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
> 
> let anEmum = E.a( a: 4 )
> 
> 
> switch anEmum {
> case

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

2017-01-24 Thread Derrick Ho via swift-evolution 
It probably is a good idea.

Perhaps the changes can be done in the Package.swift file but allow nesting
of dependencies.

Suppose your dependency is like this where P is your current project

P --> A --> B

Normally P we would describe its dependency on A while B would be
abstracted away. In A, there would be another Package.swift file describing
its dependency on B.

However if we add the ability to NEST the dependency graph in P's
Package.swift it could serve as an override to the default behavior.

import PackageDescription

let package = Package(
name: "P",
targets: [],
dependencies: [
.Package(url: "https://blah.com/A.git;,
majorVersion: 1, depdencies: [
.Package(url: "https://blahblah.com/B.git, branch: "test")
]),

]
)


On Tue, Jan 24, 2017 at 3:28 PM Daniel Dunbar via swift-evolution <
swift-evolution@swift.org> wrote:

> I am reposting this since the URLs were mangled in the original email.
>
> Hello Swift community,
>
> The review of SE-0149 “ Package Manager Support for Top of Tree
> development" begins now and runs through January 31, 2017. The proposal is
> available here:
>   https://github.com/apple/swift-evolution/blob/master/proposals/
> 0149-package-manager-top-of-tree.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>   https://lists.swift.org/mailman/listinfo/swift-build-dev
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
> • Does this proposal fit well with the feel and direction of Swift?
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
> More information about the Swift evolution process is available at
>   https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
> - Daniel
>
> Review Manager
>
> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev <
> swift-build-...@swift.org> wrote:
>
> Hello Swift community,
>
> The review of SE-0149 “ Package Manager Support for Top of Tree
> development" begins now and runs through January 31, 2017. The proposal is
> available here:
>
>
> 
> https://github.com/apple/swift-evolution/blob/master/proposal
> 
> s/*0149-package-manager-top-of-tree.md
> *
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-build-dev and swift-evolution mailing lists at
>
> https://lists.swift.org/mailman/listinfo/swift-build-dev
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> - Daniel
>
> Review Manager
> ___
> swift-build-dev mailing list
>

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 10:14 AM, Chris Eidhof  wrote:
> 
> Hey Matthew, 
> 
> Do you have an example of doing parser combinators without FP? I'd be very 
> interest

Hey Chris, looks like Dave provided a pretty good example of the kind of thing 
I was talking about.  Does that answer your questions?

> 
> On Tue, Jan 24, 2017 at 4:52 PM, Matthew Johnson  > wrote:
> 
>> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution 
>> > wrote:
>> 
>> I agree that being able to implement parsers in a nice way can be a huge 
>> step forward in being really good at string processing.
>> 
>> There are a couple of possibilities that come to mind directly:
>> 
>> 1. Build parsers right into the language (like Perl 6 grammars)
>> 2. Provide a parser combinator language (e.g. 
>> https://github.com/davedufresne/SwiftParsec 
>> ). 
>> 3. Rely on external tools like bison/yacc/etc.
>> 4. Make it easy for people to write hand-written parsers (e.g. by providing 
>> an NSScanner alternative).
>> 
>> Some obvious drawbacks of each approach:
>> 
>> 1. Lots of work, probably hard to get right?
>> 2. Only way to do this, afaik, is using lots of functional programming which 
>> might scare people off. Also probably it's hard to get performance as fast 
>> as 1.
> 
> FWIW, it is quite possible to do things very similar to parser combinators 
> without functional programming.  What you need is a way to create and compose 
> small parser fragments, ideally an EDSL approaching something like EBNF that 
> allows users to build a grammar out of the parser fragments, and a way to 
> execute / interpret the resulting grammar during parsing.  
> 
> I'd love to see this. Do you mean "possible today" or "it would be possible”?
> 
> One really big thing that I took away learning parser combinators is that 
> grammars are composable, whereas parsers themselves are not. Parser 
> combinators express grammars.
> 
> For example, when you have a Swift parser available, and you want to "embed" 
> it inside a Markdown parser, that's hard to do. Whereas composing the 
> Markdown grammar with the Swift grammar is a lot easier.
> 
> It'd be nice to have that composability.
> 
> Chris
>  
> 
> The functional approach would not be the most idiomatic approach in Swift and 
> as you note, it probably wouldn’t have the performance a more idiomatic 
> approach could achieve (too much copying).
> 
> My intuition is that a hybrid 1 / 2 approach might be best: do as much as 
> possible in the library and let the design drive new language enhancements 
> where necessary.
> 
>> 3. No clear integrated way to do this
>> 4. You still have to know how to write a parser.
>> 
>> I would think that 4. would be a good step forward, and 1/2 would definitely 
>> benefit from this.
>> 
>> Also, I'd love to have this functionality on sequence/collection types, 
>> rather than Strings. For example, it can be tremendously helpful to parse a 
>> binary format using proper parsers. Or maybe you would want to use an 
>> event-driven XML parser as "tokenizer" and parse that. Plenty of cool 
>> possibilities.
>> 
>> On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution 
>> > wrote:
>> 
>>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
 
 On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution 
 > wrote:
 
 
> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado  > wrote:
> 
> Taken from NSHipster :
> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has 
> the most long-winded and byzantine regular expression interface you’re 
> ever likely to come across.
> 
> There is no way to achieve the goal of being better at string processing 
> than Perl without regular expressions being addressed. It just should not 
> be ignored. 
 
 
 We’re certainly not ignoring the importance of regexes. But if there’s a 
 key takeaway from your experiences with NSRegularExpression, it’s that a 
 good regex implementation matters, a lot. That’s why we don’t want to rush 
 one in alongside the rest of the overhaul of String. Instead, we should 
 take our time to make it really great, and building on a solid foundation 
 of a good String API that’s already in place should help ensure that.
>>> 
>>> I do think that there's some danger to focusing too narrowly on regular 
>>> expressions as they appear in languages today. I think the industry has 
>>> largely moved on to fully-structured

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Daniel Duan via swift-evolution 

> On Jan 24, 2017, at 3:51 PM, Christopher Kornher  wrote:
> 
>> 
>> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I'm now confused who is arguing for what. Enums cases cannot have the same 
>> name. As far as I'm aware, this proposal does not seek to change that. Each 
>> case must still be unique. It only changes whether labels are regarded as 
>> part of the name or part of the associated type.
> 
> Labels are currently neither part of the name nor part of the associated 
> type. See my example (it runs in the playground in Xcode 8.2.1).
> 
> Forgive any lack of precise terminology:  Labels for enums with associated 
> values are currently only used to create a "function signature" for 
> constructing values for the enum. They are ignored in all other uses of the 
> enum AFAIK.

Here’s how the labels can be used elsewhere in Swift 3, following your example:

switch theCurrentWay {
case .a(a: let x):
switch x {
case .anInt(value: let x):
break
case .aString(value: let x):
break
}
}

Note changing the label `a` or `value` before `:` to anything else results in 
compile error. 

> 
> My proposal is a way to allow multiple cases with the same name without 
> breaking existing code. It has the benefit of giving enums a richer meaning, 
> in simple English:
> 
> Here is an example of a way to handle this currently and what it would become:
> 
> // Runs now
> enum MultipleTypes {
> case anInt( value: Int )
> case aString( value: String )
> }
> 
> enum E {
> case a( a: MultipleTypes )
> }
> 
> let theCurrentWay = E.a( a: .aString( value: "str") )
> 
> switch theCurrentWay {
> case .a( let x ) :
> switch x {
> case .anInt( let x ) :
> break
> 
> case .aString( let x ) :
> break
> }
> }
> 
> // Proposed:
> 
> /*
> enum theNewWay {
>  case a( value: Int ) :
>  case a( value: String ) :
> }
> 
> switch theCurrentWay {
> case .a( let x: Int ) :
> break
> 
> case .a( let x: String ) :
> break
> }
> */
> 
> 
>> 
>> 
>> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution 
>> > wrote:
>>> On Jan 24, 2017, at 4:02 PM, Daniel Duan >> > wrote:
>>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
 
 
 Daniel Duan
 Sent from my iPhone
 
 On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
 > wrote:
 
> I agree that  this rule would be consistent with the handing of Swift 
> function signatures, but my proposal is self-consistent and:
> 
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed 
> and in past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently 
> legal but would not be if the enum case “name” is the entire signature 
> for constructing it:
> 
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
> 
> let anEmum = E.a( a: 4 )
> 
> 
> switch anEmum {
> case .a( let x ) :
> break
> case .b( let x ) :
> break
> }
> 
> switch anEmum {
> case .a( let y ) :
> break
> 
> case .b( let y ) :
> break
> }
> ```
> So is this proposal worth creating a breaking change? I don’t think so.  
> it would be possible to ignore the associated parameter name, but not the 
> type, but that would further confuse case matching, I believe.
> 
> I personally don’t see much purpose in having two enum cases with the 
> same name if they are always treated as distinct and there is no way to 
> reason on the case name.
 
 Would you say the same for functions? Our opinions differ in what 
 constitute a "name". In Swift, function names include parameters. Each 
 enum case declares a function that creates a enum value. That's why it's 
 *more* consistent for enum to have a similar definition of "name".
 
 As for pattern matching, number of patterns the number of cases being 
 matched have a many-to-one relationships. This is true in Swift and many 
 
>>> 
>>> (Ah, accidentally sent it on my iPhone. My apologies.)
>>> 
>>> … other languages. What you are proposing complicates the rules by making 
>>> this untrue. We'd have to special-case this feature in our pattern matching 
>>> algorithm.
>> 
>> I am not proposing a

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Xiaodi Wu via swift-evolution 
Yes, but *this* proposal is precisely to make the label part of the name.


On Tue, Jan 24, 2017 at 17:51 Christopher Kornher  wrote:

> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm now confused who is arguing for what. Enums cases cannot have the same
> name. As far as I'm aware, this proposal does not seek to change that. Each
> case must still be unique. It only changes whether labels are regarded as
> part of the name or part of the associated type.
>
>
> Labels are currently neither part of the name nor part of the associated
> type. See my example (it runs in the playground in Xcode 8.2.1).
>
> Forgive any lack of precise terminology:  Labels for enums with associated
> values are currently only used to create a "function signature" for
> constructing values for the enum. They are ignored in all other uses of the
> enum AFAIK.
>
> My proposal is a way to allow multiple cases with the same name without
> breaking existing code. It has the benefit of giving enums a richer
> meaning, in simple English:
>
> Here is an example of a way to handle this currently and what it would
> become:
>
> // Runs now
> enum MultipleTypes {
> case anInt( value: Int )
> case aString( value: String )
> }
>
> enum E {
> case a( a: MultipleTypes )
> }
>
> let theCurrentWay = E.a( a: .aString( value: "str") )
>
> switch theCurrentWay {
> case .a( let x ) :
> switch x {
> case .anInt( let x ) :
> break
>
> case .aString( let x ) :
> break
> }
> }
>
> // Proposed:
>
> /*
> enum theNewWay {
>  case a( value: Int ) :
>  case a( value: String ) :
> }
>
> switch theCurrentWay {
> case .a( let x: Int ) :
> break
>
> case .a( let x: String ) :
> break
> }
> */
>
>
>
>
> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 24, 2017, at 4:02 PM, Daniel Duan  wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that  this rule would be consistent with the handing of Swift
> function signatures, but my proposal is self-consistent and:
>
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed and
> in past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently legal
> but would not be if the enum case “name” is the entire signature for
> constructing it:
>
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
>
> let anEmum = E.a( a: 4 )
>
>
> switch anEmum {
> case .a( let x ) :
> break
> case .b( let x ) :
> break
> }
>
> switch anEmum {
> case .a( let y ) :
> break
>
> case .b( let y ) :
> break
> }
> ```
> So is this proposal worth creating a breaking change? I don’t think so.
>  it would be possible to ignore the associated parameter name, but not the
> type, but that would further confuse case matching, I believe.
>
> I personally don’t see much purpose in having two enum cases with the same
> name if they are always treated as distinct and there is no way to reason
> on the case name.
>
>
> Would you say the same for functions? Our opinions differ in what
> constitute a "name". In Swift, function names include parameters. Each enum
> case declares a function that creates a enum value. That's why it's *more*
> consistent for enum to have a similar definition of "name".
>
> As for pattern matching, number of patterns the number of cases being
> matched have a many-to-one relationships. This is true in Swift and many
>
>
> (Ah, accidentally sent it on my iPhone. My apologies.)
>
> … other languages. What you are proposing complicates the rules by making
> this untrue. We'd have to special-case this feature in our pattern matching
> algorithm.
>
>
> I am not proposing a breaking change. I believe that it is the best way to
> handle “overloading” enum names without breaking existing code. I don’t
> believe that this proposal changes any existing logic or rules.
>
> The use of the terms "name” and "signature" is well established in many
> languages. e.g.: https://en.wikipedia.org/wiki/Type_signature I am trying
> to use the terms in this context.
>
> Sharing a function name (with different signatures)  is an aid to
> understanding the purpose of functions and is part of many languages. I do
> not believe that extending the concept to enums is worth the cost,
> especially since it will break existing Swift code.
>
> You are proposing a source breaking change and I do not agree that is is
> an improvement. What is the benefit of

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Christopher Kornher via swift-evolution 

> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I'm now confused who is arguing for what. Enums cases cannot have the same 
> name. As far as I'm aware, this proposal does not seek to change that. Each 
> case must still be unique. It only changes whether labels are regarded as 
> part of the name or part of the associated type.

Labels are currently neither part of the name nor part of the associated type. 
See my example (it runs in the playground in Xcode 8.2.1).

Forgive any lack of precise terminology:  Labels for enums with associated 
values are currently only used to create a "function signature" for 
constructing values for the enum. They are ignored in all other uses of the 
enum AFAIK.

My proposal is a way to allow multiple cases with the same name without 
breaking existing code. It has the benefit of giving enums a richer meaning, in 
simple English:

Here is an example of a way to handle this currently and what it would become:

// Runs now
enum MultipleTypes {
case anInt( value: Int )
case aString( value: String )
}

enum E {
case a( a: MultipleTypes )
}

let theCurrentWay = E.a( a: .aString( value: "str") )

switch theCurrentWay {
case .a( let x ) :
switch x {
case .anInt( let x ) :
break

case .aString( let x ) :
break
}
}

// Proposed:

/*
enum theNewWay {
 case a( value: Int ) :
 case a( value: String ) :
}

switch theCurrentWay {
case .a( let x: Int ) :
break

case .a( let x: String ) :
break
}
*/


> 
> 
> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution 
> > wrote:
>> On Jan 24, 2017, at 4:02 PM, Daniel Duan > > wrote:
>> 
>> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>>> > wrote:
>>> 
 I agree that  this rule would be consistent with the handing of Swift 
 function signatures, but my proposal is self-consistent and:
 
 1) It is more powerful, matching on the case name or not as required.
 2) Is consistent with existing switches that ignore associated values
 3) Is constant with ignored labels in other Swift constructs (proposed and 
 in past versions of Swift, at least)
 4) Avoids a possible API change for current enums. This is currently legal 
 but would not be if the enum case “name” is the entire signature for 
 constructing it:
 
 ```
 enum E {
 case a( a: Int )
 case b( a: Int )
 }
 
 let anEmum = E.a( a: 4 )
 
 
 switch anEmum {
 case .a( let x ) :
 break
 case .b( let x ) :
 break
 }
 
 switch anEmum {
 case .a( let y ) :
 break
 
 case .b( let y ) :
 break
 }
 ```
 So is this proposal worth creating a breaking change? I don’t think so.  
 it would be possible to ignore the associated parameter name, but not the 
 type, but that would further confuse case matching, I believe.
 
 I personally don’t see much purpose in having two enum cases with the same 
 name if they are always treated as distinct and there is no way to reason 
 on the case name.
>>> 
>>> Would you say the same for functions? Our opinions differ in what 
>>> constitute a "name". In Swift, function names include parameters. Each enum 
>>> case declares a function that creates a enum value. That's why it's *more* 
>>> consistent for enum to have a similar definition of "name".
>>> 
>>> As for pattern matching, number of patterns the number of cases being 
>>> matched have a many-to-one relationships. This is true in Swift and many 
>>> 
>> 
>> (Ah, accidentally sent it on my iPhone. My apologies.)
>> 
>> … other languages. What you are proposing complicates the rules by making 
>> this untrue. We'd have to special-case this feature in our pattern matching 
>> algorithm.
> 
> I am not proposing a breaking change. I believe that it is the best way to 
> handle “overloading” enum names without breaking existing code. I don’t 
> believe that this proposal changes any existing logic or rules.
> 
> The use of the terms "name” and "signature" is well established in many 
> languages. e.g.: https://en.wikipedia.org/wiki/Type_signature 
>  I am trying to use the terms 
> in this context.
> 
> Sharing a function name (with different signatures)  is an aid to 
> understanding the purpose of functions and is part of many languages. I do 
> not believe that extending the concept to enums is worth the cost,

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Daniel Duan via swift-evolution 
Just to be clear (so may previous point may make more sense), the “name” in the 
function `func f(x: Int, y: Int) {}` is `f(x:y:)`. The name of `f(a: Int, b: 
Int) {}` does *not* share a name with the previous function. That’s what I 
refer to when I talk about names. I would not consider these two being both 
declared as “overloading”. Here’s a function that I would say is overloading 
`f(x:y:)`: `func f(x: String, y: String)`.

One of the benefits (as stated in the motivation section of the proposal) is to 
make enum case’s name consistent with functions in Swift.

> On Jan 24, 2017, at 3:16 PM, Christopher Kornher  wrote:
> 
>> 
>> On Jan 24, 2017, at 4:02 PM, Daniel Duan > > wrote:
>> 
>> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
>>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>>> > wrote:
>>> 
 I agree that  this rule would be consistent with the handing of Swift 
 function signatures, but my proposal is self-consistent and:
 
 1) It is more powerful, matching on the case name or not as required.
 2) Is consistent with existing switches that ignore associated values
 3) Is constant with ignored labels in other Swift constructs (proposed and 
 in past versions of Swift, at least)
 4) Avoids a possible API change for current enums. This is currently legal 
 but would not be if the enum case “name” is the entire signature for 
 constructing it:
 
 ```
 enum E {
 case a( a: Int )
 case b( a: Int )
 }
 
 let anEmum = E.a( a: 4 )
 
 
 switch anEmum {
 case .a( let x ) :
 break
 case .b( let x ) :
 break
 }
 
 switch anEmum {
 case .a( let y ) :
 break
 
 case .b( let y ) :
 break
 }
 ```
 So is this proposal worth creating a breaking change? I don’t think so.  
 it would be possible to ignore the associated parameter name, but not the 
 type, but that would further confuse case matching, I believe.
 
 I personally don’t see much purpose in having two enum cases with the same 
 name if they are always treated as distinct and there is no way to reason 
 on the case name.
>>> 
>>> Would you say the same for functions? Our opinions differ in what 
>>> constitute a "name". In Swift, function names include parameters. Each enum 
>>> case declares a function that creates a enum value. That's why it's *more* 
>>> consistent for enum to have a similar definition of "name".
>>> 
>>> As for pattern matching, number of patterns the number of cases being 
>>> matched have a many-to-one relationships. This is true in Swift and many 
>>> 
>> 
>> (Ah, accidentally sent it on my iPhone. My apologies.)
>> 
>> … other languages. What you are proposing complicates the rules by making 
>> this untrue. We'd have to special-case this feature in our pattern matching 
>> algorithm.
> 
> I am not proposing a breaking change. I believe that it is the best way to 
> handle “overloading” enum names without breaking existing code. I don’t 
> believe that this proposal changes any existing logic or rules.
> 
> The use of the terms "name” and "signature" is well established in many 
> languages. e.g.: https://en.wikipedia.org/wiki/Type_signature 
>  I am trying to use the terms 
> in this context.
> 
> Sharing a function name (with different signatures)  is an aid to 
> understanding the purpose of functions and is part of many languages. I do 
> not believe that extending the concept to enums is worth the cost, especially 
> since it will break existing Swift code.
> 
> You are proposing a source breaking change and I do not agree that is is an 
> improvement. What is the benefit of this change?
> 
> 
>> 
 If they are always distinct, then requiring different names eliminates 
 unnecessary cognitive load. There is a good reason for functions to have 
 the same “name” and different signatures, and there are precedents in many 
 languages. 
 
 You may disagree, but I believe that enums exist to support reasoning on 
 distinct cases and that muddying that by treating the associated value as 
 part of the “signature" increases the language “surface area” while adding 
 no tangible benefit.
 
 
> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>> > wrote:
>>

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread Karl Wagner via swift-evolution 

> On 24 Jan 2017, at 05:10, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> While it looks nicer without the angle brackets, that suggestion is 
> unresponsive to David's point that we need some way to distinguish defaulted 
> generic arguments from inferred generic arguments.
> 
> Consider:
> ```
> let a: Optional = 1 // Optional
> 
> enum FloatPreferringOptional {
>   case some(T)
>   case none
> }
> 
> let b: FloatPreferringOptional = 1
> // Does this give you an FloatPreferringOptional?
> ```
> 
> If the answer to the above question is "yes, T is inferred as Int" then we 
> need some way to express "give me the default for T, which is Float." If the 
> answer to the above question is "no" then we need some way to express "don't 
> give me the default; rather, infer type T from the right hand side."
> 
> 
> On Mon, Jan 23, 2017 at 6:30 PM, Matthew Johnson via swift-evolution 
> > wrote:
> This proposal looks good to me.  I have been looking forward to more flexible 
> generic arguments for a while.
> 
> I agree with previous commenters who prefer the option to leave off the angle 
> brackets when all parameters have defaults.
> 
> The proposal specifically mentions that the syntax is inspired by that of 
> function arguments.  This is good, but I wonder if maybe we should draw 
> further inspiration from function arguments and also add parameter labels for 
> generic arguments.  Both feel like low hanging fruit in the generics area 
> (correct me if I’m wrong about that) and it would be great to see both 
> enhancements make it into Swift 4.
> 
>> On Jan 23, 2017, at 9:55 AM, Srđan Rašić via swift-evolution 
>> > wrote:
>> 
>> Hi Everyone,
>> 
>> I've opened a PR (https://github.com/apple/swift-evolution/pull/591 
>> ) proposing default 
>> generic arguments which I think would be nice addition to the language. They 
>> are also mentioned in "Generic manifesto". 
>> 
>> The proposal is focusing around generic types. Generic functions are not 
>> coved by the proposal and I don't think that we need default generic 
>> arguments in generic functions as all the types are always part of the 
>> function signature so the compiler can always infer them. One corner case 
>> might be if using default argument values in which case support for default 
>> generic arguments in functions might be useful.
>> 
>> It would be great to hear your opinions and suggestions so I can refine the 
>> proposal.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I was watching this talk recently by Bjarne Stroustrup 
(https://youtu.be/2egL4y_VpYg?t=26m34s 
), he was saying that when new things 
are added to a language, people tend to want very loud syntax just because it’s 
new and people want it to be obvious and fool-proof. That’s why C++ syntax is 
such a mess.

Personally, I’m fine leaving the angle brackets away if there is a default 
value. If the expected type is not the one inferred by the initialiser, you 
will hit compiler errors and be able to explicitly say which value the 
parameter should have. It’s not an unreasonable cognitive load.

- Karl


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

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread Xiaodi Wu via swift-evolution 
As I replied above, this doesn't work IMO because omitted generic arguments
are inferred, and that can't change without being hugely source-breaking.

I think it's absolutely essential that adding a default to my library
doesn't change the behavior of code that uses my library. That's currently
the case, afaict, for all default arguments, and so I think it's essential
here.


On Tue, Jan 24, 2017 at 17:26 Srđan Rašić via swift-evolution <
swift-evolution@swift.org> wrote:

> We are probably taking the wrong direction here and trying to solve the
> problem that does not need solving. We are discussing how to infer
> gereneric arguments in type declarations while we should not do that at
> all.
>
> Let me repeat Doug's examples:
>
>
> struct X { }
>
> func f1() -> X { return X() }
>
> func f2() -> X { return X() }
> func f2() -> X { return X() }
>
> func f3(_: T) -> X { return X() }
>
> let x1: X = f1()   // okay: x1 has type X?
> let x2: X = f2()   // ambiguous?
> let x3a: X = f3(1.5)   // okay: x3a has type X?
> let x3b: X = f3(1)   // okay: x3a has type X?
>
> Thinking about what the generic argument of X should be inferred to for
> x1, x2 and x3 is pointless. If one omits generic arguments in the variable
> declaration, one is accepting the defaults. In other words, doing let x: X
> = ... should always be treated as doing let x: X = ..., regardless of
> what we have on the right hand side. No inference should happen in this
> case. It would mean inferring already specified type.
>
> Why? Consider what happens if we define x as a property:
>
> struct Test {
>   let x: X
>
>   init() {
> x = f()
>   }
> }
>
> It would make no sense that the initialization in the initializer
> specializes the generic argument of the property, so for the sake of
> consistency we should not do it for the variables/constants either.
>
> Given that, we can solve Doug's example as:
>
> let x1: X = f1() // error: cannot assign X to X
>
> let x2: X = f2()   // ok: using X overload
> let x3a: X = f3(1.5)   // error like in x1
> let x3b: X = f3(1)   // ok because rhs is inferred as X
>
> I think this is the only valid way to go and it really simplifies things,
> both the understanding of how the feature works, but also the
> implementation.
>
> What do you think?
>
>
> tir. 24. jan. 2017 kl. 22.16 skrev David Sweeris :
>
>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for
> some discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Xiaodi Wu via swift-evolution 
I'm now confused who is arguing for what. Enums cases cannot have the same
name. As far as I'm aware, this proposal does not seek to change that. Each
case must still be unique. It only changes whether labels are regarded as
part of the name or part of the associated type.


On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 24, 2017, at 4:02 PM, Daniel Duan  wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Daniel Duan
> Sent from my iPhone
>
> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that  this rule would be consistent with the handing of Swift
> function signatures, but my proposal is self-consistent and:
>
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed and
> in past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently legal
> but would not be if the enum case “name” is the entire signature for
> constructing it:
>
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
>
> let anEmum = E.a( a: 4 )
>
>
> switch anEmum {
> case .a( let x ) :
> break
> case .b( let x ) :
> break
> }
>
> switch anEmum {
> case .a( let y ) :
> break
>
> case .b( let y ) :
> break
> }
> ```
> So is this proposal worth creating a breaking change? I don’t think so.
>  it would be possible to ignore the associated parameter name, but not the
> type, but that would further confuse case matching, I believe.
>
> I personally don’t see much purpose in having two enum cases with the same
> name if they are always treated as distinct and there is no way to reason
> on the case name.
>
>
> Would you say the same for functions? Our opinions differ in what
> constitute a "name". In Swift, function names include parameters. Each enum
> case declares a function that creates a enum value. That's why it's *more*
> consistent for enum to have a similar definition of "name".
>
> As for pattern matching, number of patterns the number of cases being
> matched have a many-to-one relationships. This is true in Swift and many
>
>
> (Ah, accidentally sent it on my iPhone. My apologies.)
>
> … other languages. What you are proposing complicates the rules by making
> this untrue. We'd have to special-case this feature in our pattern matching
> algorithm.
>
>
> I am not proposing a breaking change. I believe that it is the best way to
> handle “overloading” enum names without breaking existing code. I don’t
> believe that this proposal changes any existing logic or rules.
>
> The use of the terms "name” and "signature" is well established in many
> languages. e.g.: https://en.wikipedia.org/wiki/Type_signature I am trying
> to use the terms in this context.
>
> Sharing a function name (with different signatures)  is an aid to
> understanding the purpose of functions and is part of many languages. I do
> not believe that extending the concept to enums is worth the cost,
> especially since it will break existing Swift code.
>
> You are proposing a source breaking change and I do not agree that is is
> an improvement. What is the benefit of this change?
>
>
>
> If they are always distinct, then requiring different names eliminates
> unnecessary cognitive load. There is a good reason for functions to have
> the same “name” and different signatures, and there are precedents in many
> languages.
>
> You may disagree, but I believe that enums exist to support reasoning on
> distinct cases and that muddying that by treating the associated value as
> part of the “signature" increases the language “surface area” while adding
> no tangible benefit.
>
>
> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Your example is only has only one case, which is not typical. Perhaps I am
> missing something, but the only reason that I can imagine for having a case
> with multiple ways to “construct” it is to have all variants of the case to
> match. If you don’t want them to match, use a different case name.
>
>
> It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are
> the full case names.  These are *not* the same case.  The `bar` shorthand
> is allowed when there is no ambiguity, however for an enum with both
> `bar(a:)` and `bar(b:)` there *is* ambiguity and therefore the `bar`
> shorthand is not allowed.  The programmer is required to spell out the full
> name of the case they wish to match.
>
>
>
> It would still be possible to match on the different types of bar when
>

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread Xiaodi Wu via swift-evolution 
That does not comport with the definition of "default." I would disagree
with that treatment. Nor does it seem consistent with current syntax. If I
have a type Foo, then inference works when someone writes `let a: Foo =
...`. If I add a default to my type

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread Srđan Rašić via swift-evolution 
We are probably taking the wrong direction here and trying to solve the
problem that does not need solving. We are discussing how to infer
gereneric arguments in type declarations while we should not do that at
all.

Let me repeat Doug's examples:


struct X { }

func f1() -> X { return X() }

func f2() -> X { return X() }
func f2() -> X { return X() }

func f3(_: T) -> X { return X() }

let x1: X = f1()   // okay: x1 has type X?
let x2: X = f2()   // ambiguous?
let x3a: X = f3(1.5)   // okay: x3a has type X?
let x3b: X = f3(1)   // okay: x3a has type X?

Thinking about what the generic argument of X should be inferred to for x1,
x2 and x3 is pointless. If one omits generic arguments in the variable
declaration, one is accepting the defaults. In other words, doing let x: X
= ... should always be treated as doing let x: X = ..., regardless of
what we have on the right hand side. No inference should happen in this
case. It would mean inferring already specified type.

Why? Consider what happens if we define x as a property:

struct Test {
  let x: X

  init() {
x = f()
  }
}

It would make no sense that the initialization in the initializer
specializes the generic argument of the property, so for the sake of
consistency we should not do it for the variables/constants either.

Given that, we can solve Doug's example as:

let x1: X = f1() // error: cannot assign X to X

let x2: X = f2()   // ok: using X overload
let x3a: X = f3(1.5)   // error like in x1
let x3b: X = f3(1)   // ok because rhs is inferred as X

I think this is the only valid way to go and it really simplifies things,
both the understanding of how the feature works, but also the
implementation.

What do you think?


tir. 24. jan. 2017 kl. 22.16 skrev David Sweeris :

>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for
> some discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Christopher Kornher via swift-evolution 

> On Jan 24, 2017, at 4:02 PM, Daniel Duan  wrote:
> 
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
> > wrote:
> 
>> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>>> I agree that  this rule would be consistent with the handing of Swift 
>>> function signatures, but my proposal is self-consistent and:
>>> 
>>> 1) It is more powerful, matching on the case name or not as required.
>>> 2) Is consistent with existing switches that ignore associated values
>>> 3) Is constant with ignored labels in other Swift constructs (proposed and 
>>> in past versions of Swift, at least)
>>> 4) Avoids a possible API change for current enums. This is currently legal 
>>> but would not be if the enum case “name” is the entire signature for 
>>> constructing it:
>>> 
>>> ```
>>> enum E {
>>> case a( a: Int )
>>> case b( a: Int )
>>> }
>>> 
>>> let anEmum = E.a( a: 4 )
>>> 
>>> 
>>> switch anEmum {
>>> case .a( let x ) :
>>> break
>>> case .b( let x ) :
>>> break
>>> }
>>> 
>>> switch anEmum {
>>> case .a( let y ) :
>>> break
>>> 
>>> case .b( let y ) :
>>> break
>>> }
>>> ```
>>> So is this proposal worth creating a breaking change? I don’t think so.  it 
>>> would be possible to ignore the associated parameter name, but not the 
>>> type, but that would further confuse case matching, I believe.
>>> 
>>> I personally don’t see much purpose in having two enum cases with the same 
>>> name if they are always treated as distinct and there is no way to reason 
>>> on the case name.
>> 
>> Would you say the same for functions? Our opinions differ in what constitute 
>> a "name". In Swift, function names include parameters. Each enum case 
>> declares a function that creates a enum value. That's why it's *more* 
>> consistent for enum to have a similar definition of "name".
>> 
>> As for pattern matching, number of patterns the number of cases being 
>> matched have a many-to-one relationships. This is true in Swift and many 
>> 
> 
> (Ah, accidentally sent it on my iPhone. My apologies.)
> 
> … other languages. What you are proposing complicates the rules by making 
> this untrue. We'd have to special-case this feature in our pattern matching 
> algorithm.

I am not proposing a breaking change. I believe that it is the best way to 
handle “overloading” enum names without breaking existing code. I don’t believe 
that this proposal changes any existing logic or rules.

The use of the terms "name” and "signature" is well established in many 
languages. e.g.: https://en.wikipedia.org/wiki/Type_signature 
 I am trying to use the terms in 
this context.

Sharing a function name (with different signatures)  is an aid to understanding 
the purpose of functions and is part of many languages. I do not believe that 
extending the concept to enums is worth the cost, especially since it will 
break existing Swift code.

You are proposing a source breaking change and I do not agree that is is an 
improvement. What is the benefit of this change?


> 
>>> If they are always distinct, then requiring different names eliminates 
>>> unnecessary cognitive load. There is a good reason for functions to have 
>>> the same “name” and different signatures, and there are precedents in many 
>>> languages. 
>>> 
>>> You may disagree, but I believe that enums exist to support reasoning on 
>>> distinct cases and that muddying that by treating the associated value as 
>>> part of the “signature" increases the language “surface area” while adding 
>>> no tangible benefit.
>>> 
>>> 
 On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
 > wrote:
 
> 
> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
> > wrote:
> 
> Your example is only has only one case, which is not typical. Perhaps I 
> am missing something, but the only reason that I can imagine for having a 
> case with multiple ways to “construct” it is to have all variants of the 
> case to match. If you don’t want them to match, use a different case 
> name. 
 
 It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are 
 the full case names.  These are *not* the same case.  The `bar` shorthand 
 is allowed when there is no ambiguity, however for an enum with both 
 `bar(a:)` and `bar(b:)` there *is* ambiguity and therefore the `bar` 
 shorthand is not allowed.  The programmer is required to spell out the 
 full name of the case they wish to match.
 
 
> 
> It would still be possible

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Daniel Duan via swift-evolution 


Daniel Duan
Sent from my iPhone

> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>>  wrote:
>> 
>> I agree that  this rule would be consistent with the handing of Swift 
>> function signatures, but my proposal is self-consistent and:
>> 
>> 1) It is more powerful, matching on the case name or not as required.
>> 2) Is consistent with existing switches that ignore associated values
>> 3) Is constant with ignored labels in other Swift constructs (proposed and 
>> in past versions of Swift, at least)
>> 4) Avoids a possible API change for current enums. This is currently legal 
>> but would not be if the enum case “name” is the entire signature for 
>> constructing it:
>> 
>> ```
>> enum E {
>> case a( a: Int )
>> case b( a: Int )
>> }
>> 
>> let anEmum = E.a( a: 4 )
>> 
>> 
>> switch anEmum {
>> case .a( let x ) :
>> break
>> case .b( let x ) :
>> break
>> }
>> 
>> switch anEmum {
>> case .a( let y ) :
>> break
>> 
>> case .b( let y ) :
>> break
>> }
>> ```
>> So is this proposal worth creating a breaking change? I don’t think so.  it 
>> would be possible to ignore the associated parameter name, but not the type, 
>> but that would further confuse case matching, I believe.
>> 
>> I personally don’t see much purpose in having two enum cases with the same 
>> name if they are always treated as distinct and there is no way to reason on 
>> the case name.
> 
> Would you say the same for functions? Our opinions differ in what constitute 
> a "name". In Swift, function names include parameters. Each enum case 
> declares a function that creates a enum value. That's why it's *more* 
> consistent for enum to have a similar definition of "name".
> 
> As for pattern matching, number of patterns the number of cases being matched 
> have a many-to-one relationships. This is true in Swift and many 
> 

(Ah, accidentally sent it on my iPhone. My apologies.)

… other languages. What you are proposing complicates the rules by making this 
untrue. We'd have to special-case this feature in our pattern matching 
algorithm.

>> If they are always distinct, then requiring different names eliminates 
>> unnecessary cognitive load. There is a good reason for functions to have the 
>> same “name” and different signatures, and there are precedents in many 
>> languages. 
>> 
>> You may disagree, but I believe that enums exist to support reasoning on 
>> distinct cases and that muddying that by treating the associated value as 
>> part of the “signature" increases the language “surface area” while adding 
>> no tangible benefit.
>> 
>> 
 On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
  wrote:
 
 Your example is only has only one case, which is not typical. Perhaps I am 
 missing something, but the only reason that I can imagine for having a 
 case with multiple ways to “construct” it is to have all variants of the 
 case to match. If you don’t want them to match, use a different case name. 
>>> 
>>> It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are 
>>> the full case names.  These are *not* the same case.  The `bar` shorthand 
>>> is allowed when there is no ambiguity, however for an enum with both 
>>> `bar(a:)` and `bar(b:)` there *is* ambiguity and therefore the `bar` 
>>> shorthand is not allowed.  The programmer is required to spell out the full 
>>> name of the case they wish to match.
>>> 
>>> 
 
 It would still be possible to match on the different types of bar when 
 needed:
 
 ```
 enum Foo {
 case bar(a: Int)
 case bar(b: String)
 case notAbar
 }
 
 
  switch aFoo {
 case .bar( let a: Int) : // matches Ints only 
...
 
 case .bar( let b: String) : // matches Strings only
...
 }
 
 switch aFoo {
 case .bar :  // Matches both  cases and that is a good thing
…
 
 case notAbar:
….
 }
 
 ```
 
> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I would imagine it would be logical to have it work just like it does now 
> with functions. If case bar is distinct, then that should still work, but 
> if bar is "overloaded," then case bar should be invalid for ambiguity. 
> Seems fine to me, shouldn't break any existing code and therefore we 
> don't lose anything.
> 
> 
>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 24 Jan 2017, at 00:52,

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Jonathan Hull via swift-evolution 

> On Jan 24, 2017, at 7:52 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution 
>> > wrote:
>> 
>> I agree that being able to implement parsers in a nice way can be a huge 
>> step forward in being really good at string processing.
>> 
>> There are a couple of possibilities that come to mind directly:
>> 
>> 1. Build parsers right into the language (like Perl 6 grammars)
>> 2. Provide a parser combinator language (e.g. 
>> https://github.com/davedufresne/SwiftParsec 
>> ). 
>> 3. Rely on external tools like bison/yacc/etc.
>> 4. Make it easy for people to write hand-written parsers (e.g. by providing 
>> an NSScanner alternative).
>> 
>> Some obvious drawbacks of each approach:
>> 
>> 1. Lots of work, probably hard to get right?
>> 2. Only way to do this, afaik, is using lots of functional programming which 
>> might scare people off. Also probably it's hard to get performance as fast 
>> as 1.
> 
> FWIW, it is quite possible to do things very similar to parser combinators 
> without functional programming.  What you need is a way to create and compose 
> small parser fragments, ideally an EDSL approaching something like EBNF that 
> allows users to build a grammar out of the parser fragments, and a way to 
> execute / interpret the resulting grammar during parsing.  
> 
> The functional approach would not be the most idiomatic approach in Swift and 
> as you note, it probably wouldn’t have the performance a more idiomatic 
> approach could achieve (too much copying).
> 
> My intuition is that a hybrid 1 / 2 approach might be best: do as much as 
> possible in the library and let the design drive new language enhancements 
> where necessary.

Yes, the first program I wrote in Swift was a packrat parser (now used in 
several of my projects).  It uses custom operators to let you write the grammar 
directly in swift, which is nice because it can be combined directly with code 
which gets run when a rule is matched.  

One of the most time consuming parts of that was writing a custom string 
scanner.  I would really like to see support for basic string scanning, 
including a standard library implementation of something like NSCharacterSet, 
built into the new String.  Or rather, I would like features built in which 
make building a string scanner trivial and lightweight.  Basically just a 
couple of methods saying things like: given an index and a character set, 
return a range including the contiguous group of characters in that set 
directly after the index (with options for case/diacritic sensitivity, etc…).  
With that and better slices, it should be fairly easy to build a 
lightweight/efficient scanner... 


>> 3. No clear integrated way to do this
>> 4. You still have to know how to write a parser.
>> 
>> I would think that 4. would be a good step forward, and 1/2 would definitely 
>> benefit from this.
>> 
>> Also, I'd love to have this functionality on sequence/collection types, 
>> rather than Strings. For example, it can be tremendously helpful to parse a 
>> binary format using proper parsers. Or maybe you would want to use an 
>> event-driven XML parser as "tokenizer" and parse that. Plenty of cool 
>> possibilities.
>> 
>> On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution 
>> > wrote:
>> 
>>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
 
 On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution 
 > wrote:
 
 
> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado  > wrote:
> 
> Taken from NSHipster :
> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has 
> the most long-winded and byzantine regular expression interface you’re 
> ever likely to come across.
> 
> There is no way to achieve the goal of being better at string processing 
> than Perl without regular expressions being addressed. It just should not 
> be ignored. 
 
 
 We’re certainly not ignoring the importance of regexes. But if there’s a 
 key takeaway from your experiences with NSRegularExpression, it’s that a 
 good regex implementation matters, a lot. That’s why we don’t want to rush 
 one in alongside the rest of the overhaul of String. Instead, we should 
 take our time to make it really great, and building on a solid foundation 
 of a good String API that’s already in place should help ensure that.
>>> 
>>> I do think that there's some danger to focusing too narrowly on regular 
>>>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Daniel Duan via swift-evolution 


Daniel Duan
Sent from my iPhone

> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> I agree that  this rule would be consistent with the handing of Swift 
> function signatures, but my proposal is self-consistent and:
> 
> 1) It is more powerful, matching on the case name or not as required.
> 2) Is consistent with existing switches that ignore associated values
> 3) Is constant with ignored labels in other Swift constructs (proposed and in 
> past versions of Swift, at least)
> 4) Avoids a possible API change for current enums. This is currently legal 
> but would not be if the enum case “name” is the entire signature for 
> constructing it:
> 
> ```
> enum E {
> case a( a: Int )
> case b( a: Int )
> }
> 
> let anEmum = E.a( a: 4 )
> 
> 
> switch anEmum {
> case .a( let x ) :
> break
> case .b( let x ) :
> break
> }
> 
> switch anEmum {
> case .a( let y ) :
> break
> 
> case .b( let y ) :
> break
> }
> ```
> So is this proposal worth creating a breaking change? I don’t think so.  it 
> would be possible to ignore the associated parameter name, but not the type, 
> but that would further confuse case matching, I believe.
> 
> I personally don’t see much purpose in having two enum cases with the same 
> name if they are always treated as distinct and there is no way to reason on 
> the case name.

Would you say the same for functions? Our opinions differ in what constitute a 
"name". In Swift, function names include parameters. Each enum case declares a 
function that creates a enum value. That's why it's *more* consistent for enum 
to have a similar definition of "name".

As for pattern matching, number of patterns the number of cases being matched 
have a many-to-one relationships. This is true in Swift and many 

> If they are always distinct, then requiring different names eliminates 
> unnecessary cognitive load. There is a good reason for functions to have the 
> same “name” and different signatures, and there are precedents in many 
> languages. 
> 
> You may disagree, but I believe that enums exist to support reasoning on 
> distinct cases and that muddying that by treating the associated value as 
> part of the “signature" increases the language “surface area” while adding no 
> tangible benefit.
> 
> 
>>> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>>>  wrote:
>>> 
>>> Your example is only has only one case, which is not typical. Perhaps I am 
>>> missing something, but the only reason that I can imagine for having a case 
>>> with multiple ways to “construct” it is to have all variants of the case to 
>>> match. If you don’t want them to match, use a different case name. 
>> 
>> It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are 
>> the full case names.  These are *not* the same case.  The `bar` shorthand is 
>> allowed when there is no ambiguity, however for an enum with both `bar(a:)` 
>> and `bar(b:)` there *is* ambiguity and therefore the `bar` shorthand is not 
>> allowed.  The programmer is required to spell out the full name of the case 
>> they wish to match.
>> 
>> 
>>> 
>>> It would still be possible to match on the different types of bar when 
>>> needed:
>>> 
>>> ```
>>> enum Foo {
>>> case bar(a: Int)
>>> case bar(b: String)
>>> case notAbar
>>> }
>>> 
>>> 
>>>  switch aFoo {
>>> case .bar( let a: Int) : // matches Ints only 
>>> ...
>>> 
>>> case .bar( let b: String) : // matches Strings only
>>>...
>>> }
>>> 
>>> switch aFoo {
>>> case .bar :  // Matches both  cases and that is a good thing
>>> …
>>> 
>>> case notAbar:
>>> ….
>>> }
>>> 
>>> ```
>>> 
 On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
  wrote:
 
 I would imagine it would be logical to have it work just like it does now 
 with functions. If case bar is distinct, then that should still work, but 
 if bar is "overloaded," then case bar should be invalid for ambiguity. 
 Seems fine to me, shouldn't break any existing code and therefore we don't 
 lose anything.
 
 
> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>  wrote:
> 
> 
>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> We're not terribly principled about this right now with non-pattern 
>> declaration references. You can still reference an unapplied function by 
>> its base name alone without its labels, if it's unambiguous:
>> 
>> func foo(x: Int, y: Int) {}
>> 
>> let foo_x_y: (Int, Int) -> () = foo
>> 
>> so it'd be consistent to continue to allow the same in pattern 
>> references.
>

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Tue Jan 24 2017, Olivier Tardieu  wrote:

> Thanks for the great write-up!
>
> The manifesto recognizes the importance of machine processing and 
> performance.
> I am surprised that there is no mention of any kind of "unsafe" strings or 
> string processing.
> In general, Swift does an amazing job at incorporating unsafe mechanism 
> into a safe-by-default programming paradigm.
> But for some reason, Strings seem to be left out of the unsafe
> discussion.

Maybe it wasn't clear from the document, but the intention is that
String would be able to use any model of Unicode as a backing store, and
that you could easily build unsafe models of Unicode... but also that
you could use your unsafe model of Unicode directly, in string-ish ways.

> A lot of machine processing of strings continues to deal with 8-bit 
> quantities (even 7-bit quantities, not UTF-8).
> Swift strings are not very good at that. I see progress in the manifesto 
> but nothing to really close the performance gap with C.
> That's where "unsafe" mechanisms could come into play.

extendedASCII is supposed to address that.  Given a smart enough
optimizer, it should be possible to become competitive with C even
without using unsafe constructs.  However, we recognize the importance
of being able to squeeze out that last bit of performance by dropping
down to unsafe storage.

> To guarantee Unicode correctness, a C string must be validated or 
> transformed to be considered a Swift string.

Not really.  You can do error-correction on the fly.  However, I think
pre-validation is often worthwhile because once you know something is
valid it's much cheaper to decode correctly (especially for UTF-8).

> If I understand the C String interop section correctly, in Swift 4,
> this should not force a copy, but traversing the string is still
> required.  

*What* should not force a copy?

> I hope I am correct about the no-copy thing, and I would also like to
> permit promoting C strings to Swift strings without validation.  This
> is obviously unsafe in general, but I know my strings... and I care
> about performance. ;)

We intend to support that use-case.  That's part of the reason for the
ValidUTF8 and ValidUTF16 encodings you see here:
https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L598
and here:
https://github.com/apple/swift/blob/unicode-rethink/stdlib/public/core/Unicode2.swift#L862

> More importantly, it is not possible to mutate bytes in a Swift string
> at will.  Again it makes sense from the point of view of always
> correct Unicode sequences.  But it does not for machine processing of
> C strings with C-like performance.  Today, I can cheat using a
> "_public" API for this, i.e., myString._core.  _baseAddress!.  This
> should be doable from an official "unsafe" API.

We intend to support that use-case.

> Memory safety is also at play here, as well as ownership.  A proper
> API could guarantee the backing store is writable for instance, that
> it is not shared.  A memory-safe but not unicode-safe API could do
> bounds checks.
>
> While low-level C string processing can be done using unsafe memory
> buffers with performance, the lack of bridging with "real" Swift
> strings kills the deal.  No literals syntax (or costly coercions),
> none of the many useful string APIs.
>
> To illustrate these points here is a simple experiment: code written
> to synthesize an http date string from a bunch of integers.  There are
> four versions of the code going from nice high-level Swift code to
> low-level C-like code.  (Some of this code is also about avoiding ARC
> overheads, and string interpolation overheads, hence the four
> versions.)
>
> On my macbook pro (swiftc -O), the performance is as follows:
>
> interpolation + func:  2.303032365s
> interpolation + array: 1.224858418s
> append:0.918512377s
> memcpy:0.182104674s
>
> While the benchmarking could be done more carefully, I think the main
> observation is valid.  The nice code is more than 10x slower than the
> C-like code.  Moreover, the ugly-but-still-valid-Swift code is still
> about 5x slower than the C like code.  For some applications, e.g. web
> servers, this kind of numbers matter...
>
> Some of the proposed improvements would help with this, e.g., small
> strings optimization, and maybe changes to the concatenation
> semantics.  But it seems to me that a big performance gap will remain.
> (Concatenation even with strncat is significantly slower than memcpy
> for fixed-size strings.)
>
> I believe there is a need and an opportunity for a fast "less safe"
> String API.  I hope it will be on the roadmap soon.

I think it's already in the roadmap...the one that's in my head.  If you
want to submit a PR with amendments to the manifesto, that'd be great.
Also thanks very much for the example below; we'll definitely
be referring to it as we proceed forward.

>
>
> Best,
>
> Olivier
>
> import Foundation
>
> // get current

[swift-evolution] [Draft] Test-Only Package Dependencies and Targets

2017-01-24 Thread Robert Widmann via swift-evolution 
Hello Swift Community,

Harlan Haskins and I have been working on libraries 
 to make interacting with LLVM and Clang’s APIs 
more elegant with native Swift interfaces.  While writing up the packages we 
realized the package manager wouldn’t allow us to specify testing targets and 
test-only dependencies.  To rectify that, I have attached a draft proposal for 
adding test-only targets and dependency fields to the Swift Package manager.  
This proposal can also be read in gist form 
.

Cheers,

~Robert Widmann

Test-Only Package Dependencies and Targets

Proposal: SE- 
Authors: Harlan Haskins , Robert Widmann 

Review Manager: TBD
Status: Awaiting review
 
Introduction

This proposal reinstates Swift package manager’s ability to fetch dependencies 
and build targets scoped exclusively to the testing module(s) of a given 
package.

Swift-evolution thread: Discussion thread topic for that proposal 

 
Motivation

Soon after SE-0019 

 identified the need for richer test-only dependencies and targets, a decision 
was made to remove the package manager’s fledgling ability to treat certain 
dependencies as test-only. This has led to a myriad of 
clever-but-needlessly-complex workarounds ([1] 
, 
[2] , [3] 
) on the part 
of 3rd parties to recover the feature themselves. In addition, the Swift 
community has come up with a number of their own frameworks to augment 
functionality in XCTest but depending on these external testing frameworks is 
brittle and difficult to get right.

 
Proposed
 solution

We propose the re-introduction of the testDependencies parameter in Package 
Manifests to support external test-only dependencies. To support local 
test-only targets we also propose the introduction of the testTargets parameter 
and an extension of the existing swift test command to support individual 
invocation of these targets.

 
Detailed
 design

The behavior of the new testDependencies parameter mirrors that of the existing 
dependencies parameter with one important difference: fetched dependencies are 
only built to support package-defined test targets as part of an invocation of 
swift test.

import PackageDescription

let package = Package(
name: "Foo",
targets: [
Target(name: "Foo")
],
dependencies: [
.Package(url: "https://github.com/org/ana.git;, versions: 
Version(1,0,0)...Version(1,9,9)),
],
testDependencies: [
.Package(url: "https://github.com/org/anism.git;, versions: 
Version(1,0,0)...Version(1,9,9)),
]
)
Similarly, the behavior of the testTargets field mirrors that of the existing 
targets field but defines a set of targets that are only built during an 
invocation of swift test. Importantly, a target defined in testTargets may 
reference a target defined in targets but not vice-versa. Should that behavior 
be needed, the test target should be promoted to a “full” target.

import PackageDescription

let package = Package(
name: "SwiftPM",
targets: [
Target(
name: "PackageDescription",
dependencies: []),

// MARK: Support libraries

Target(
/** Cross-platform access to bare `libc` functionality. */
name: "libc",
dependencies: []),
Target(
/** “Swifty” POSIX functions from libc */
name: "POSIX",
dependencies: ["libc"]),
Target(
/** Basic support library */
name: "Basic",
dependencies: ["libc", "POSIX"]),

/* Omitted for Brevity */
 ],
 testTargets: [
Target(
name: "BasicPerformanceTests",
dependencies: ["Basic"]),
   /* Omitted for Brevity */
 ]
 )
Finally, with well-defined test targets in hand, we propose swift test be 
amended to support individual test execution.

We propose the following syntax to execute all tests of all known test targets.

$ swift test
To run a set of specific test cases, reference the module-defining test target 
and the specific name of a subclass of XCTestCase:

$ swift test TestModule.TestCase
To run

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread T.J. Usiyan via swift-evolution 
I like this approach as a first pass. It leaves room for other, more
forgiving strategies later and is relatively easy to explain.

On Tue, Jan 24, 2017 at 4:16 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 24, 2017, at 11:41, Alexis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It’s worth noting that the question of “how do these defaults interact
> with other defaults” is an issue that has left this feature dead in the
> water in the Rust language despite being accepted for inclusion two years
> ago. See https://internals.rust-lang.org/t/interaction-of-
> user-defined-and-integral-fallbacks-with-inference/2496 for some
> discussion of the issues at hand.
>
> For those who don’t want to click that link, or are having trouble
> translating the syntax/terms to Swift. The heart of Niko’s post is the
> following (note: functions are used here for expedience; you can imagine
> these are `inits` for a generic type if you wish):
>
> // Example 1: user supplied default is IntegerLiteralConvertible
>
> func

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Christopher Kornher via swift-evolution 
I agree that  this rule would be consistent with the handing of Swift function 
signatures, but my proposal is self-consistent and:

1) It is more powerful, matching on the case name or not as required.
2) Is consistent with existing switches that ignore associated values
3) Is constant with ignored labels in other Swift constructs (proposed and in 
past versions of Swift, at least)
4) Avoids a possible API change for current enums. This is currently legal but 
would not be if the enum case “name” is the entire signature for constructing 
it:

```
enum E {
case a( a: Int )
case b( a: Int )
}

let anEmum = E.a( a: 4 )


switch anEmum {
case .a( let x ) :
break
case .b( let x ) :
break
}

switch anEmum {
case .a( let y ) :
break

case .b( let y ) :
break
}
```
So is this proposal worth creating a breaking change? I don’t think so.  it 
would be possible to ignore the associated parameter name, but not the type, 
but that would further confuse case matching, I believe.

I personally don’t see much purpose in having two enum cases with the same name 
if they are always treated as distinct and there is no way to reason on the 
case name. If they are always distinct, then requiring different names 
eliminates unnecessary cognitive load. There is a good reason for functions to 
have the same “name” and different signatures, and there are precedents in many 
languages. 

You may disagree, but I believe that enums exist to support reasoning on 
distinct cases and that muddying that by treating the associated value as part 
of the “signature" increases the language “surface area” while adding no 
tangible benefit.


> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution 
> > wrote:
> 
>> 
>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>> Your example is only has only one case, which is not typical. Perhaps I am 
>> missing something, but the only reason that I can imagine for having a case 
>> with multiple ways to “construct” it is to have all variants of the case to 
>> match. If you don’t want them to match, use a different case name. 
> 
> It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are 
> the full case names.  These are *not* the same case.  The `bar` shorthand is 
> allowed when there is no ambiguity, however for an enum with both `bar(a:)` 
> and `bar(b:)` there *is* ambiguity and therefore the `bar` shorthand is not 
> allowed.  The programmer is required to spell out the full name of the case 
> they wish to match.
> 
> 
>> 
>> It would still be possible to match on the different types of bar when 
>> needed:
>> 
>> ```
>> enum Foo {
>> case bar(a: Int)
>> case bar(b: String)
>> case notAbar
>> }
>> 
>> 
>>  switch aFoo {
>> case .bar( let a: Int) : // matches Ints only 
>>  ...
>> 
>> case .bar( let b: String) : // matches Strings only
>>...
>> }
>> 
>> switch aFoo {
>> case .bar :  // Matches both  cases and that is a good thing
>>  …
>> 
>> case notAbar:
>>  ….
>> }
>> 
>> ```
>> 
>>> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> I would imagine it would be logical to have it work just like it does now 
>>> with functions. If case bar is distinct, then that should still work, but 
>>> if bar is "overloaded," then case bar should be invalid for ambiguity. 
>>> Seems fine to me, shouldn't break any existing code and therefore we don't 
>>> lose anything.
>>> 
>>> 
>>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
 We're not terribly principled about this right now with non-pattern 
 declaration references. You can still reference an unapplied function by 
 its base name alone without its labels, if it's unambiguous:
 
 func foo(x: Int, y: Int) {}
 
 let foo_x_y: (Int, Int) -> () = foo
 
 so it'd be consistent to continue to allow the same in pattern references.
>>> 
>>> WRT ambiguity, do we loose the ability to pattern match on the naked case 
>>> name when two cases share the same base name?
>>> 
>>> enum Foo {
>>> case bar(a: Int)
>>> case bar(b: String)
>>> }
>>> 
>>> switch aFoo {
>>> case .bar: // matches both cases
>>> break
>>> }
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>>>

Re: [swift-evolution] A case for postponing ABI stability

2017-01-24 Thread Joe Groff via swift-evolution 

> On Jan 24, 2017, at 12:15 PM, Freak Show via swift-evolution 
>  wrote:
> 
> I do not see how you can consider standardizing ABI without first 
> standardizing the dynamic features and the desired programmatic interfaces to 
> them.  
> 
> We know that dynamic features need to come.  They will impact everything.  My 
> personal ideal is a language that smoothly transitions from fully dynamic to 
> fully static without a lot of fuss. 

There will inevitably be features at some point that require added runtime 
support that won't backward-deploy to older runtime versions. However, a lot of 
the information you'd need for many dynamic features is already there, and 
planned to be stabilized as part of the ABI. We already emit reflection data 
that describes the physical layouts of types, and once those formats are 
stabilized, building a library that interprets the metadata is additive (and 
could conceivably be done by a third party independent of the standard 
library). There may not be metadata for individual methods yet, but there is 
tracking of protocol conformances, and once the standard library protocols are 
stabilized, someone could make assumptions about the protocol witness table 
layouts for those protocols to find particular method implementations even if 
you're running on an older standard library without the full method metadata we 
might support one day.

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> Your example is only has only one case, which is not typical. Perhaps I am 
> missing something, but the only reason that I can imagine for having a case 
> with multiple ways to “construct” it is to have all variants of the case to 
> match. If you don’t want them to match, use a different case name. 

It sounds like you are missing something.  The `bar(a:)` and `bar(b:)` are the 
full case names.  These are *not* the same case.  The `bar` shorthand is 
allowed when there is no ambiguity, however for an enum with both `bar(a:)` and 
`bar(b:)` there *is* ambiguity and therefore the `bar` shorthand is not 
allowed.  The programmer is required to spell out the full name of the case 
they wish to match.


> 
> It would still be possible to match on the different types of bar when needed:
> 
> ```
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> case notAbar
> }
> 
> 
>  switch aFoo {
> case .bar( let a: Int) : // matches Ints only 
>   ...
> 
> case .bar( let b: String) : // matches Strings only
>...
> }
> 
> switch aFoo {
> case .bar :  // Matches both  cases and that is a good thing
>   …
> 
> case notAbar:
>   ….
> }
> 
> ```
> 
>> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I would imagine it would be logical to have it work just like it does now 
>> with functions. If case bar is distinct, then that should still work, but if 
>> bar is "overloaded," then case bar should be invalid for ambiguity. Seems 
>> fine to me, shouldn't break any existing code and therefore we don't lose 
>> anything.
>> 
>> 
>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
>> > wrote:
>> 
>>> We're not terribly principled about this right now with non-pattern 
>>> declaration references. You can still reference an unapplied function by 
>>> its base name alone without its labels, if it's unambiguous:
>>> 
>>> func foo(x: Int, y: Int) {}
>>> 
>>> let foo_x_y: (Int, Int) -> () = foo
>>> 
>>> so it'd be consistent to continue to allow the same in pattern references.
>> 
>> WRT ambiguity, do we loose the ability to pattern match on the naked case 
>> name when two cases share the same base name?
>> 
>> enum Foo {
>> case bar(a: Int)
>> case bar(b: String)
>> }
>> 
>> switch aFoo {
>> case .bar: // matches both cases
>> break
>> }
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread David Sweeris via swift-evolution 

> On Jan 24, 2017, at 11:41, Alexis via swift-evolution 
>  wrote:
> 
> It’s worth noting that the question of “how do these defaults interact with 
> other defaults” is an issue that has left this feature dead in the water in 
> the Rust language despite being accepted for inclusion two years ago. See 
> https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
>  for some discussion of the issues at hand.
> 
> For those who don’t want to click that link, or are having trouble 
> translating the syntax/terms to Swift. The heart of Niko’s post is the 
> following (note: functions are used here for expedience; you can imagine 
> these are `inits` for a generic type if you wish):
> 
> // Example 1: user supplied default is IntegerLiteralConvertible
> 
> func

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Christopher Kornher via swift-evolution 
Your example is only has only one case, which is not typical. Perhaps I am 
missing something, but the only reason that I can imagine for having a case 
with multiple ways to “construct” it is to have all variants of the case to 
match. If you don’t want them to match, use a different case name. 

It would still be possible to match on the different types of bar when needed:

```
enum Foo {
case bar(a: Int)
case bar(b: String)
case notAbar
}


 switch aFoo {
case .bar( let a: Int) : // matches Ints only 
...

case .bar( let b: String) : // matches Strings only
   ...
}

switch aFoo {
case .bar :  // Matches both  cases and that is a good thing
…

case notAbar:
….
}

```

> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I would imagine it would be logical to have it work just like it does now 
> with functions. If case bar is distinct, then that should still work, but if 
> bar is "overloaded," then case bar should be invalid for ambiguity. Seems 
> fine to me, shouldn't break any existing code and therefore we don't lose 
> anything.
> 
> 
> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
> > wrote:
> 
> 
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
> > wrote:
> 
>> We're not terribly principled about this right now with non-pattern 
>> declaration references. You can still reference an unapplied function by its 
>> base name alone without its labels, if it's unambiguous:
>> 
>> func foo(x: Int, y: Int) {}
>> 
>> let foo_x_y: (Int, Int) -> () = foo
>> 
>> so it'd be consistent to continue to allow the same in pattern references.
> 
> WRT ambiguity, do we loose the ability to pattern match on the naked case 
> name when two cases share the same base name?
> 
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> }
> 
> switch aFoo {
> case .bar: // matches both cases
> break
> }
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

2017-01-24 Thread Daniel Dunbar via swift-evolution 
I am reposting this since the URLs were mangled in the original email.

Hello Swift community,

The review of SE-0149 “ Package Manager Support for Top of Tree development" 
begins now and runs through January 31, 2017. The proposal is available here:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-build-dev and swift-evolution mailing lists at
  https://lists.swift.org/mailman/listinfo/swift-build-dev
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?
More information about the Swift evolution process is available at
  https://github.com/apple/swift-evolution/blob/master/process.md 


Thank you,
- Daniel

Review Manager

> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0149 “ Package Manager Support for Top of Tree development" 
> begins now and runs through January 31, 2017. The proposal is available here:
> 
>  
> https://github.com/apple/swift-evolution/blob/master/proposal
>  
> s/0149-package-manager-top-of-tree.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
> 
> https://lists.swift.org/mailman/listinfo/swift-build-dev 
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md
>  
> 
> Reply text
> 
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> - Daniel
> 
> Review Manager
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

Re: [swift-evolution] [draft] Compound Names For Enum Cases

2017-01-24 Thread Daniel Duan via swift-evolution 
Great suggestion. Done.
> On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution 
>  wrote:
> 
> Ok, sounds logical. Might be worth adding that info to the proposal to make 
> it clear how ambiguity plays out.
> 
>> On 24 Jan 2017, at 13:27, Xiaodi Wu > > wrote:
>> 
>> I would imagine it would be logical to have it work just like it does now 
>> with functions. If case bar is distinct, then that should still work, but if 
>> bar is "overloaded," then case bar should be invalid for ambiguity. Seems 
>> fine to me, shouldn't break any existing code and therefore we don't lose 
>> anything.
>> 
>> 
>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
>> > wrote:
>> 
>>> We're not terribly principled about this right now with non-pattern 
>>> declaration references. You can still reference an unapplied function by 
>>> its base name alone without its labels, if it's unambiguous:
>>> 
>>> func foo(x: Int, y: Int) {}
>>> 
>>> let foo_x_y: (Int, Int) -> () = foo
>>> 
>>> so it'd be consistent to continue to allow the same in pattern references.
>> 
>> WRT ambiguity, do we loose the ability to pattern match on the naked case 
>> name when two cases share the same base name?
>> 
>> enum Foo {
>> case bar(a: Int)
>> case bar(b: String)
>> }
>> 
>> switch aFoo {
>> case .bar: // matches both cases
>> break
>> }
>> ___
>> 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] A case for postponing ABI stability

2017-01-24 Thread Freak Show via swift-evolution 
I do not see how you can consider standardizing ABI without first standardizing 
the dynamic features and the desired programmatic interfaces to them.  

We know that dynamic features need to come.  They will impact everything.  My 
personal ideal is a language that smoothly transitions from fully dynamic to 
fully static without a lot of fuss. 



> On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution 
>  wrote:
> 
> I agree that we shouldn't rush decisions but I feel like the emphasis of ABI 
> stability has been a factor in discussing a number of proposals for Swift 4 
> and has been a core goal of this next major release. Seems strange to 
> deemphasize it and its importance at this time.
> 
> Below are some thoughts from my perspective as someone involved in the 
> decision to adopt Swift in production at work.
> 
> ABI Stability
> The reality is that stability in the ABI is important for a number of 
> developers and companies considering adopting or that have already adopted 
> Swift. Shipping the runtime increases the binary size of every app that ships 
> with it and becomes a barrier in user acquisition due to the increased app 
> size. If I'm not mistaken this issue multiplies as you add extensions to your 
> application since they all bundle the runtime separately. Due to these 
> issues, ABI Stability is one of the leading reasons we have not adopted Swift 
> in our flagship app.
> 
> API Stability
> This I would consider just as important as the ABI stability. Changing APIs 
> provides a lot of churn on developers that manage large codebases and I've 
> often heard of issues using the Swift migrator at scale which doesn't help. 
> I'd like to see a less drastic approach like Jonathan is suggesting where we 
> have clear indication of APIs that might change or at least allowing one 
> minor release where an API will warn if it's used but is still available to 
> allow developers time to migrate.
> 
> Right now I think it's important to keep ABI stability as a core tenant of 
> any proposal and acknowledge that we need to just flag how proposals will 
> affect ABI stability. This seems inline with our stance on the development of 
> a Rust-inspired `Memory Ownership Model`: "While a full memory ownership 
> model is likely too large for Swift 4 stage 1, we need a comprehensive design 
> to understand how it will change the ABI."
> 
> On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution 
> > wrote:
> > I'm not really sure if the String-changes affect the ABI, but none the 
> > less, I strongly agree with your opinion that things shouldn't be done in a 
> > hurry, and I hope that Swift keeps the courage to break things for the 
> > better (sporadically ;-)
> 
> +1
> 
> ___
> 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] Reduce with inout

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 1:27 PM, Xiaodi Wu  wrote:
> 
> Hmm, brainstorming here. Given the pervasive use of `with` to mean "this 
> isn't accessible otherwise but inside this closure it's $0", maybe 
> `reduce(with: 42) { $0 += 1 }` might give a useful hint?

Are there any current uses of `with` passed `inout`?

> On Tue, Jan 24, 2017 at 13:19 Matthew Johnson  > wrote:
>> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu > > wrote:
>> 
>> Hmm, it reads well, but IMO it avoids being misleading only because it 
>> doesn't mean anything. In what way are you reducing "into" the first 
>> argument any more so than the classic reduce function?
> 
> It isn't perfect, but it’s better than the alternatives I’ve seen so far.
> 
> In the classic reduce function a new value is produced for each step of the 
> reduction.  In this variation, each step reduces “into” an accumulator that 
> is initialized with the seed value.  In that sense, you could say that you 
> reduce “into” the seed value.
> 
> Labeling the argument `into` is a little bit of a stretch but I think it's 
> far superior to `mutating` which is pretty misleading at the call site.  I 
> think it would be pretty hard to come up with something better, but let’s 
> keep the bikeshed going if anyone has additional ideas.
> 
> 
>> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution 
>> > wrote:
>>> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> Freak Show wrote:
>>> 
 Am I the only one who finds this incredibly ugly and hard to read?
 
 This is more or less solved by inject:into: idiom.  There is no reason for 
 inout for this particular problem.
>>> 
>>> Yeah, the original signature seems more useful. If you go all `inout` like 
>>> Gwendal suggested, you might as well just iterate over the sequence with 
>>> `for x in xs`, updating the state as you go.
>>> 
>>> But your comment brought another idea to mind: if `mutating:` is considered 
>>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>>> similar to what Karl suggested earlier in this thread?
>>> 
>>> I think it reads very well at the call site, does not suggest `inout`ness 
>>> of the argument too much (of course there's no `&` at the call site 
>>> either), and it's still easily found with auto-completion:
>>> 
>>> let counts = words.reduce(into: [:]) {
>>>   $0[$1] = ($0[$1] ?? 0) + 1
>>> }
>> 
>> +1.  This is concise and I think it captures the essence of what is 
>> happening pretty well!
>> 
>> The third variation where the seed argument actually *is* `inout` might also 
>> be interesting in some cases where you *already* have a `var` that you want 
>> to accumulate into.  I believe I have done this in the past in my own code 
>> but don’t have an example handy.
>> 
>>> 
>>> — Pyry
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 

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

Re: [swift-evolution] Default Generic Arguments

2017-01-24 Thread Alexis via swift-evolution 
It’s worth noting that the question of “how do these defaults interact with 
other defaults” is an issue that has left this feature dead in the water in the 
Rust language despite being accepted for inclusion two years ago. See 
https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
 

 for some discussion of the issues at hand.

For those who don’t want to click that link, or are having trouble translating 
the syntax/terms to Swift. The heart of Niko’s post is the following (note: 
functions are used here for expedience; you can imagine these are `inits` for a 
generic type if you wish):

// Example 1: user supplied default is IntegerLiteralConvertible

func

Re: [swift-evolution] A case for postponing ABI stability

2017-01-24 Thread Rahul Malik via swift-evolution 
I agree that we shouldn't rush decisions but I feel like the emphasis of
ABI stability has been a factor in discussing a number of proposals for
Swift 4 and has been a core goal of this next major release. Seems strange
to deemphasize it and its importance at this time.

Below are some thoughts from my perspective as someone involved in the
decision to adopt Swift in production at work.

*ABI Stability*
The reality is that stability in the ABI is important for a number of
developers and companies considering adopting or that have already adopted
Swift. Shipping the runtime increases the binary size of every app that
ships with it and becomes a barrier in user acquisition due to the
increased app size. If I'm not mistaken this issue multiplies as you add
extensions to your application since they all bundle the runtime
separately. Due to these issues, ABI Stability is one of the leading
reasons we have not adopted Swift in our flagship app.

*API Stability*
This I would consider just as important as the ABI stability. Changing APIs
provides a lot of churn on developers that manage large codebases and I've
often heard of issues using the Swift migrator at scale which doesn't help.
I'd like to see a less drastic approach like Jonathan is suggesting where
we have clear indication of APIs that might change or at least allowing one
minor release where an API will warn if it's used but is still available to
allow developers time to migrate.

Right now I think it's important to keep ABI stability as a core tenant of
any proposal and acknowledge that we need to just flag how proposals will
affect ABI stability. This seems inline with our stance on the development
of a Rust-inspired `Memory Ownership Model`: "While a full memory ownership
model is likely too large for Swift 4 stage 1, we need a comprehensive
design to understand how it will change the ABI."

On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution <
swift-evolution@swift.org> wrote:

> > I'm not really sure if the String-changes affect the ABI, but none the
> less, I strongly agree with your opinion that things shouldn't be done in a
> hurry, and I hope that Swift keeps the courage to break things for the
> better (sporadically ;-)
>
> +1
>
> ___
> 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] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Mon Jan 23 2017, Félix Cloutier  wrote:

>> Le 23 janv. 2017 à 20:45, Dave Abrahams  a
> écrit :
>> 
>> 
>> 
>> 
>> 
>> On Jan 22, 2017, at 9:54 PM, Félix Cloutier  > wrote:
>> 
>>> 
> doesn't necessarily mean that ignoring that case is the right
> thing to do. In fact, it means that Unicode won't do anything to
> protect programs against these, and if Swift doesn't, chances are that
> no one will. Isolated combining characters break a number of
> expectations that developers could reasonably have:
> 
> (a + b).count == a.count + b.count
> (a + b).startsWith(a)
> (a + b).endsWith(b)
> (a + b).find(a) // or .find(b)
> 
> Of course, this can be documented, but people want easy, and 
> documentation is hard.
 
 Yes.  Unfortunately they also want the ability to append a string
 consisiting of a combining character to another string and have it
 append.  And they don't want to be prevented from forming
 valid-but-defective Unicode strings.
 
 […]
 
 Can you suggest an alternative that doesn't violate the Unicode
 standard and supports the expected use-cases, somehow?
>>> 
>>> 
>>> I'm not sure I understand. Did we go from "this is a
>>> degenerate/defective
>>> 
>>> case that we shouldn't bother with" to "this is a supported use case
>>> that needs to work as-is"?
>> 
>> No.  The Unicode standard says it's a valid string, so we shouldn't
>> prohibit it.  The standard also says it's a corner case for which it
>> isn't worth making heroic efforts to create sensible semantics.  It's
>> totally in keeping with the Unicode standards that we treat it as
>> proposed.
>> 
>> In a domain as complex as String processing, we need a guiding star,
>> and that star is the Unicode standard.  I'm very reluctant to do
>> anything that clashes with the spirit of the standard.
>> 
>>> I've never seen anyone start a string with a combining character on 
>>> purpose, 
>> 
>> It will occur as a byproduct of the process of attaching a diacritic
>> to a base character.
>
> Unless you're in the business of writing a text editor, I don't know
> if that's a common use case.

I don't either, to be honest.  But the experts I consult with keep
reassuring me that it's an important one.

>>> though I'm familiar with just one natural language that needs
>>> combining characters. I can imagine that it could be a convenient
>>> feature in other natural languages.
>>> 
>>> However, if Swift Strings are now designed for machine processing
>>> and less for human language convenience, for me, it's easy enough to
>>> justify a safe default in the context of machine processing: `a+b`
>>> will not combine the end of `a` with the start of `b`. You could do
>>> this by inserting a ◌ that `b` could combine with if necessary.
>> 
>> You can do it, but it trades one semantic problem for a usability
>> problem, without solving all the semantic problems: you end up with
>> a.count + b.count == (a+b).count, sure, but you still don't satisfy
>> the usual law of collections that (a+b).contains(b.first!) if b is
>> non-empty, and now you've made it difficult to attach diacritics to
>> base characters.
>
> "Difficult".
>
> What kind of processing would you suggest on a variable "b" in the
> expression "\(a),\(b)" to ensure that the result can be split with a
> comma?

I'm sorry, I don't understand what you're driving at, here.

-- 
-Dave

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

Re: [swift-evolution] A case for postponing ABI stability

2017-01-24 Thread Michael Ilseman via swift-evolution 

> On Jan 24, 2017, at 12:12 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> Imho the major problem is that there's quite a lot confusion about what ABI 
> stability actually means — and a lot uncertainty which proposals would 
> actually affect it.

I’m hoping to clarify this very soon with a lot more information.

> People with more insight may prove me wrong, but I'll lay out my 
> understanding in the next paragraph:
> It shouldn't be hard to have several versions of the stdlib installed, and no 
> one talks about API stability (which is great as well — but a superior API 
> imho is better ;-)
> ABI is very low level and affects the junction of software and hardware 
> (which bits are put into which location when a function call happens, 
> utilisation of registers…).
> 

While ABI is low-level, at least in the sense that binary interfaces are 
low-level, a language’s ABI is actually pretty cross-cutting. All of a 
languages features and semantics that may be exposed across ABI boundaries need 
a place in the languages ABI, and Swift has a lot of features.

> I'm not really sure if the String-changes affect the ABI, but none the less, 
> I strongly agree with your opinion that things shouldn't be done in a hurry, 
> and I hope that Swift keeps the courage to break things for the better 
> (sporadically ;-)
> 

One subtlety that’s not always brought up is that when we talk about 
stabilizing the Swift ABI, what is really important is stabilizing the 
interface of libSwiftCore. libSwiftCore includes the standard library and 
language runtime, so in a hand-wavy sense the stdlib’s API is part of 
libSwiftCore's ABI. Again, much more on this soon.


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

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Mon Jan 23 2017, Brent Royal-Gordon  wrote:

>> On Jan 21, 2017, at 3:49 AM, Brent Royal-Gordon  
>> wrote:
>
> I'm going to trim out the bits where my answer is an uninteresting "Good" or 
> "Okay, we'll leave that
> for later" or what-have-you.
>
>>> The operands and sense of the comparison are kind of lost in all this 
>>> garbage. You really want to
> see `foo < bar` in this code somewhere, but you don't.
>> 
>> Yeah, we thought about trying to build a DSL for that, but failed.  I think 
>> the best possible
> option would be something like:
>> 
>>   foo.comparison(case: .insensitive, locale: .current) < bar
>> 
>> The biggest problem is that you can build things like
>> 
>> fu = foo.comparison(case: .insensitive, locale: .current)
>> br = bar.comparison(case: .sensitive)
>> fu < br // what does this mean?
>> 
>> We could even prevent such nonsense from compiling, but the cost in library 
>> API surface area is
>> quite large.
>
> Is it? I think we're talking, for each category of operation that can be 
> localized like this:
>
> * One type to carry an operand and its options.
> * One method to construct this type.
> * One alternate version of each operator which accepts an
> operand+options parameter. (I'm thinking it should always be the
> right-hand side, so the long stuff ends up at the end; Larry Wall
> noted this follows an "end-weight principle" in natural languages.)
>
> I suspect that most solutions will at least require some sort of overload on 
> the comparison
> operators, so this may be as parsimonious as we can get.

Tell you what: why don't you prototype it and see what you can come up
with?  Then we can think about the use-cases and see whether your
proposed API carries its weight.
>
>>> I'm struggling a little with the naming and syntax, but as a general 
>>> approach, I think we want
>>> people to use something more like this:
>>> 
>>>if StringOptions(case: .insensitive, locale: .current).compare(foo < 
>>> bar) { … }
>> 
>> Yeah, we can't do that without making 
>> 
>>  let a = foo < bar
>> 
>> ambiguous
>
> Yeah, that's true. Perhaps we could introduce an attribute which can
> be used to say "disfavor this overload compared to other
> possibilities", but that seems disturbingly ad-hoc.

I think we want something a feature like that, some day for other
purposes anyway.

> I know you want to defer this for now, so feel free to set this part
> of the email aside, 

I think I will :-)

> but here's a quick list of solutions I've ballparked:
>
> 1. Your "one operand carries the options" solution.
>
> 2. As I mentioned, do something that effectively overloads comparison 
> operators to return them in a
> symbolic form. You're right about the ambiguity problem, though.
>
> 3. Like #2, but with slightly modified operators, e.g.:
>
>   if localized(fu &< br, case: .insensitive) { … }
>
> 4. Reintroduce something like the old `BooleanType` and have *all* 
> comparisons construct a symbolic
> form that can be coerced to boolean. This is crazy, but actually probably 
> useful in other places; I
> once experimented with constructing NSPredicates like this.
>
>   protocol BooleanProtocol { var boolValue: Bool { get } }
>
>   struct Comparison {
>   var negated: Bool
>   var sortOrder: SortOrder
>   var left: Operand
>   var right: Operand
>
>   func evaluate(_ actualSortOrder: SortOrder) -> Bool {
>   // There's circularity problems here, because `==` 
> would itself return a
> `Comparison`,
>   // but I think you get the idea.
>   return (actualSortOrder == sortOrder) != negated
>   }
>   }
>   extension Comparison: BooleanProtocol {
>   var boolValue: Bool {
>   return evaluate(left.compared(to: right))
>   }
>   }
>
>   func < (lhs: ComparableType, rhs: 
> ComparableType) -> Comparison
> {
>   return Comparison(negated: false, sortOrder: .before, left: 
> lhs, right: rhs)
>   }
>   func <= (lhs: ComparableType, rhs: 
> ComparableType) -> Comparison
> {
>   return Comparison(negated: true, sortOrder: .after, left: lhs, 
> right: rhs)
>   }
>   // etc.
>
>   // Now for our special String comparison thing:
>   func localized(_ expr: Comparison, case: StringCaseSensitivity? 
> = nil, …) -> Bool {
>   return expr.evaluate(expr.left.compare(expr.right, case: case, 
> …))
>   }
>
> 5. Actually add some all-new piece of syntax that allows you to add options 
> to an operator. Bad part
> is that this is ugly and kind of weird; good part is that this could probably 
> be used in other
> places as well. Strawman example:
>
>   // Use:
>   if fu < br %(case: .insensitive, locale: .current) { … }
>
>   // Definition:
>   func < (lhs: String, rhs:

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Sun Jan 22 2017, James Froggatt  wrote:

> Could we add subscript labels to the list of options? While keeping
> the range syntax is appealing, I'm concerned it may cause confusion if
> the operators are used out of context.
>
> The wording is up for debate, but something like this should be a fair 
> alternative:
> items[from: i]
> items[upTo: i]

If we were to do that, I'd want to drop range notation altogether and
just require this for slicing:

  items[from: i, upTo: j]

The point here is to create a single unified idiom that can be used
everywhere.

> Sorry if this has been covered elsewhere (can't find the answer in
> this thread), but my first questions on discovering these operators
> (my source of confusion) would be what happens if I try the following:
> let partialRange = 0..< //is this an infinite range?

It is not a Range, but a RangeExpression with no upper bound.

> let x = items[partialRange] //shouldn't this cause an out of bounds error?

No, the upper bound is filled in by the collection

>  Begin Message  
> Group: gmane.comp.lang.swift.evolution 
> MsgID: <0a458383-2415-4ed4-ad28-88393a671...@nondot.org> 
>
>> On Jan 20, 2017, at 9:39 PM, Brent Royal-Gordon via swift-evolution 
>> 
> wrote:
>> 
>>> On Jan 20, 2017, at 2:45 PM, Dave Abrahams via swift-evolution 
>>>  wrote:
>>> 
>>> on Fri Jan 20 2017, Joe Groff  wrote:
>>> 
 Jordan points out that the generalized slicing syntax stomps on '...x'
 and 'x...', which would be somewhat obvious candidates for variadic
 splatting if that ever becomes a thing. Now, variadics are a much more
 esoteric feature and slicing is much more important to day-to-day
 programming, so this isn't the end of the world IMO, but it is
 something we'd be giving up.
>>> 
>>> Good point, Jordan.
>> 
>> In my experiments with introducing one-sided operators in Swift 3, I
>> was not able to find a case where you actually wanted to write
>> `c[i...]`. Everything I tried needed to use `c[i..<]` instead. My
>> conclusion was that there was no possible use for postfix `...`;
>> after all, `c[i...]` means `c[i...c.endIndex]`, which means
>> `c[i..> on `index(after:)`.
>
> Right, the only sensible semantics for a one sided range with an open
> end point is that it goes to the end of the collection.  I see a few
> different potential colors to paint this bikeshed with, all of which
> would have the semantics “c[i..
> 1) Provide "c[i...]":
> 2) Provide "c[i..<]":
> 3) Provide both "c[i..<]” and "c[i…]":
>
> Since all of these operations would have the same behavior, it comes down to 
> subjective questions:
>
> a) Do we want redundancy?  IMO, no, which is why #3 is not very desirable.
> b) Which is easier to explain to people?  As you say, "i..< is shorthand for 
> i.. and simple, which leans towards #2.
> c) Which is subjectively nicer looking?  IMO, #1 is much nicer
> typographically.  The ..< formulation looks like symbol soup,
> particularly because most folks would not put a space before ].
>
> There is no obvious winner, but to me, I tend to prefer #1.  What do other 
> folks think?
>
>> If that's the case, you can reserve postfix `...` for future variadics 
>> features, while using
> prefix `...` for these one-sided ranges.
>
> I’m personally not very worried about this, the feature doesn’t
> exist yet and there are lots of ways to spell it.  This is something
> that could and probably should deserve a more explicit/heavy syntax
> for clarity.
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> )ß
>
> - End Message - 
>
> From James
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Xiaodi Wu via swift-evolution 
Hmm, brainstorming here. Given the pervasive use of `with` to mean "this
isn't accessible otherwise but inside this closure it's $0", maybe
`reduce(with: 42) { $0 += 1 }` might give a useful hint?
On Tue, Jan 24, 2017 at 13:19 Matthew Johnson 
wrote:

> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:
>
> Hmm, it reads well, but IMO it avoids being misleading only because it
> doesn't mean anything. In what way are you reducing "into" the first
> argument any more so than the classic reduce function?
>
>
> It isn't perfect, but it’s better than the alternatives I’ve seen so far.
>
> In the classic reduce function a new value is produced for each step of
> the reduction.  In this variation, each step reduces “into” an accumulator
> that is initialized with the seed value.  In that sense, you could say that
> you reduce “into” the seed value.
>
> Labeling the argument `into` is a little bit of a stretch but I think it's
> far superior to `mutating` which is pretty misleading at the call site.  I
> think it would be pretty hard to come up with something better, but let’s
> keep the bikeshed going if anyone has additional ideas.
>
>
> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Freak Show wrote:
>
> Am I the only one who finds this incredibly ugly and hard to read?
>
> This is more or less solved by inject:into: idiom.  There is no reason for
> inout for this particular problem.
>
>
> Yeah, the original signature seems more useful. If you go all `inout` like
> Gwendal suggested, you might as well just iterate over the sequence with
> `for x in xs`, updating the state as you go.
>
> But your comment brought another idea to mind: if `mutating:` is
> considered a bad name for a non-`inout` argument, how about `
> *reduce(into:combine:)`*, similar to what Karl suggested earlier in this
> thread?
>
> I think it reads very well at the call site, does not suggest `inout`ness
> of the argument too much (of course there's no `&` at the call site
> either), and it's still easily found with auto-completion:
>
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }
>
>
> +1.  This is concise and I think it captures the essence of what is
> happening pretty well!
>
> The third variation where the seed argument actually *is* `inout` might
> also be interesting in some cases where you *already* have a `var` that you
> want to accumulate into.  I believe I have done this in the past in my own
> code but don’t have an example handy.
>
>
> — Pyry
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 1:01 PM, Xiaodi Wu  wrote:
> 
> Hmm, it reads well, but IMO it avoids being misleading only because it 
> doesn't mean anything. In what way are you reducing "into" the first argument 
> any more so than the classic reduce function?

It isn't perfect, but it’s better than the alternatives I’ve seen so far.

In the classic reduce function a new value is produced for each step of the 
reduction.  In this variation, each step reduces “into” an accumulator that is 
initialized with the seed value.  In that sense, you could say that you reduce 
“into” the seed value.

Labeling the argument `into` is a little bit of a stretch but I think it's far 
superior to `mutating` which is pretty misleading at the call site.  I think it 
would be pretty hard to come up with something better, but let’s keep the 
bikeshed going if anyone has additional ideas.


> On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution 
> > wrote:
>> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>> > wrote:
>> 
>> 
>> Freak Show wrote:
>> 
>>> Am I the only one who finds this incredibly ugly and hard to read?
>>> 
>>> This is more or less solved by inject:into: idiom.  There is no reason for 
>>> inout for this particular problem.
>> 
>> Yeah, the original signature seems more useful. If you go all `inout` like 
>> Gwendal suggested, you might as well just iterate over the sequence with 
>> `for x in xs`, updating the state as you go.
>> 
>> But your comment brought another idea to mind: if `mutating:` is considered 
>> a bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
>> similar to what Karl suggested earlier in this thread?
>> 
>> I think it reads very well at the call site, does not suggest `inout`ness of 
>> the argument too much (of course there's no `&` at the call site either), 
>> and it's still easily found with auto-completion:
>> 
>> let counts = words.reduce(into: [:]) {
>>   $0[$1] = ($0[$1] ?? 0) + 1
>> }
> 
> +1.  This is concise and I think it captures the essence of what is happening 
> pretty well!
> 
> The third variation where the seed argument actually *is* `inout` might also 
> be interesting in some cases where you *already* have a `var` that you want 
> to accumulate into.  I believe I have done this in the past in my own code 
> but don’t have an example handy.
> 
>> 
>> — Pyry
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> 
> Freak Show wrote:
> 
>> Am I the only one who finds this incredibly ugly and hard to read?
>> 
>> This is more or less solved by inject:into: idiom.  There is no reason for 
>> inout for this particular problem.
> 
> Yeah, the original signature seems more useful. If you go all `inout` like 
> Gwendal suggested, you might as well just iterate over the sequence with `for 
> x in xs`, updating the state as you go.
> 
> But your comment brought another idea to mind: if `mutating:` is considered a 
> bad name for a non-`inout` argument, how about `reduce(into:combine:)`, 
> similar to what Karl suggested earlier in this thread?
> 
> I think it reads very well at the call site, does not suggest `inout`ness of 
> the argument too much (of course there's no `&` at the call site either), and 
> it's still easily found with auto-completion:
> 
> let counts = words.reduce(into: [:]) {
>   $0[$1] = ($0[$1] ?? 0) + 1
> }

+1.  This is concise and I think it captures the essence of what is happening 
pretty well!

The third variation where the seed argument actually *is* `inout` might also be 
interesting in some cases where you *already* have a `var` that you want to 
accumulate into.  I believe I have done this in the past in my own code but 
don’t have an example handy.

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

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Pyry Jahkola via swift-evolution 

> Freak Show wrote:
> 
> Am I the only one who finds this incredibly ugly and hard to read?
> 
> This is more or less solved by inject:into: idiom.  There is no reason for 
> inout for this particular problem.

Yeah, the original signature seems more useful. If you go all `inout` like 
Gwendal suggested, you might as well just iterate over the sequence with `for x 
in xs`, updating the state as you go.

But your comment brought another idea to mind: if `mutating:` is considered a 
bad name for a non-`inout` argument, how about `reduce(into:combine:)`, similar 
to what Karl suggested earlier in this thread?

I think it reads very well at the call site, does not suggest `inout`ness of 
the argument too much (of course there's no `&` at the call site either), and 
it's still easily found with auto-completion:

let counts = words.reduce(into: [:]) {
  $0[$1] = ($0[$1] ?? 0) + 1
}

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Fri Jan 20 2017, Jonathan Hull  wrote:

>> On Jan 20, 2017, at 8:28 AM, Dave Abrahams  wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull >> > wrote:
>>> 
>>> Thanks for all the hard work!
>>> 
>>> Still digesting, but I definitely support the goal of string processing 
>>> even better than Perl.
> Some random thoughts:
>>> 
>>> • I also like the suggestion of implicit conversion from substring
> slices to strings based on a subtype relationship, since I keep
> running into that issue when trying to use array slices.
>> 
>> Interesting.  Could you offer some examples?
>
> Nothing catastrophic.  Mainly just having to wrap all of my slices in
> Array() to actually use them, which obfuscates the purpose of my
> code. It also took me an embarrassingly long time to figure out that
> was what I had to do to make it work.  

Is this because you're calling Cocoa APIs that traffic in Array?  An
alternative is to make such APIs generic on Collection instead of
Array-specific.

> For the longest time, I couldn’t understand why anyone would use
> slices because I couldn’t actually use them with any API… and then
> someone mentioned wrapping it in Array() here on Evolution and I
> finally got it.  Though it still feels like internal details that I
> shouldn’t have to worry about leaking out...

Because they have a very real performance impact, they're not strictly
internal details.

>>> It would be nice to be able to specify that conversion behavior with
>>> other types that have a similar subtype relationship.
>> 
>> Indeed.
>> 
>>> • One thing that stood out was the interpolation format syntax, which 
>>> seemed a bit convoluted and
> difficult to parse:
 "Something with leading zeroes: \(x.format(fill: zero, width:8))"
>>> 
>>> 
>>> Have you considered treating the interpolation parenthesis more
> like the function call syntax?  It should be a familiar pattern and
> easily parseable to someone versed in other areas of swift:
>>> 
>>>   “Something with leading zeroes: \(x, fill: .zero, width: 8)"
>> 
>> Yes, we've considered it
>> 
>>  1. "\(f(expr1, label2: expr2, label3: expr3))" 
>> 
>> String(describing: f(expr1, label2: expr2, label3: expr3))
>> 
>>  2. "\(expr0 + expr1(label2: expr2, label3: expr3))"
>> 
>> String(describing: expr0 + expr1(label2: expr2, label3: expr3)
>> 
>>  3. "\((expr1, label2: expr2, label3: expr3))"
>> 
>> String(describing: (expr1, label2: expr2, label3: expr3))
>> 
>>  4. "\(expr1, label2: expr2, label3: expr3)"
>> 
>> String(describing: expr1, label2: expr2, label3: expr3)
>> 
>> I think I'm primarily concerned with the differences among cases 1, 3,
>> and 4, which are extremely minor.  3 and 4 differ by just a set of
>> parentheses, though that might be mitigated by the ${...} suggestion someone 
>> else posted.  The
> point of using string interpolation is to improve
>> readability, and I fear these cases make too many things look alike that
>> have very different meanings.  Using a common term like "format" calls
>> out what is being done.
>> 
>> It's possible to produce terser versions of the syntax that don't suffer
>> from this problem by using a dedicated operator:
>> 
>>  "Column 1: \(n⛄(radix:16, width:8)) *** \(message)"
>>  "Something with leading zeroes: \(x⛄(fill: zero, width:8))"
>> 
>> or even
>> 
>>  "Column 1: \(n⛄radix:16⛄width:8) *** \(message)"
>>  "Something with leading zeroes: \(x⛄fill:zero⛄width:8)”
>
> There is still too much going on here to be readable, though I suppose
> you could put part of it on a previous line.  I really like Joe’s
> suggestion of how to handle this using an
> ExpressableByStringInterpolation protocol + sugar.  One of my favorite
> things about the current \() is how readable it makes my strings
> compared to every other language I have used!  I definitely want to
> make sure we keep that advantage...

+1

>>> 
>>> I think that should work for the common cases (e.g. padding,
> truncating, and alignment), with string-returning methods on the type
> (or even formatting objects ala NSNumberFormatter) being used for more
> exotic formatting needs (e.g. outputting a number as Hex instead of
> Decimal)
>>> 
>>> • Have you considered having an explicit .machine locale which
> means that the function should treat the string as machine readable?
> (as opposed to the lack of a locale)
>> 
>> No, we hadn't.  What would be the goal of such a design?
>
> Just to be able to explicitly spell the desired behavior (as opposed
> to only being able to rely on the lack of something).  The end usage
> would most likely be the same in most places as .machine could
> probably be the default value of the ‘locale’ parameter.  However, it
> would allow me to express my intention to other programmers (and
> future Jon) that this function is explicitly handling the string as
> machine readable.  It is a difference in feeling and expression as
>

[swift-evolution] [Review] SE-0150 Package Manager Support for branches

2017-01-24 Thread Daniel Dunbar via swift-evolution 
Hello Swift community,

The review of SE-0150 “ Package Manager Support for branches" begins now and 
runs through January 31, 2017. The proposal is available here:

  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-build-dev and swift-evolution mailing lists at
  https://lists.swift.org/mailman/listinfo/swift-build-dev
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:
  
https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md

What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

- Daniel

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Tue Jan 24 2017, Russ Bishop  wrote:

>> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> ### Formatting
>> 
>> A full treatment of formatting is out of scope of this proposal, but
>> we believe it's crucial for completing the text processing picture.  This
>> section details some of the existing issues and thinking that may guide 
>> future
>> development.
>> 
>
> Filesystem paths are Strings on Apple platforms but not on Linux. 

What, exactly, do you mean by that?

> How are we going to square that circle? What about Swift on the
> server, where distinguishing HTML and JavaScript is security-critical?
> There are huge security implications to string processing, often
> around platforms making it easy to do the wrong thing in a careless
> way and promoting ad-hoc formatting, serialization and parsing. That’s
> a huge area to consider of course but it might be worth thinking about
> how a ergonomic API for a few example cases would work.
>
> I guess my point is that formatting and interpolation is far more than
> “just formatting”; making the right thing difficult will directly lead
> to exploitable security vulnerabilities or not as the case may be. (To
> be clear I’m not saying the follow-on proposals from this need to
> solve those problems, maybe just give them some consideration).
>
>> ## Open Questions
>> 
>> ### Must `String` be limited to storing UTF-16 subset encodings?
>> 
>> - The ability to handle `UTF-8`-encoded strings (models of `Unicode`) is not 
>> in
>>  question here; this is about what encodings must be storable, without
>>  transcoding, in the common currency type called “`String`”.
>> - ASCII, Latin-1, UCS-2, and UTF-16 are UTF-16 subsets.  UTF-8 is not.
>
> Depending on who you believe UTF-8 is the encoding of ~65-88% of all
> text content transmitted over the web. JSON and XML represent the
> lion’s share of REST and non-REST APIs in use and both are almost
> exclusively transmitted as UTF-8. As you point out with extendedASCII,
> a lot of markup and structure is ASCII even if the content is not so
> UTF-8 represents a significant size savings even on Chinese/Japanese
> web pages that require 3 bytes to represent many characters (the
> savings on markup overwhelming the loss on textual content).
>
> Any model that makes using UTF-8 backed Strings difficult or
> cumbersome to use can have a negative performance and memory impact. I
> don’t have a good idea of the actual cost but it might be worth doing
> some test to determine that.
>
> Is NSString interop the only reason to not just use UTF-8 as the
> default storage? 

Perhaps more universally important is interop with ICU, which also
requires UTF-16 in most places.

None of this necessarily means String won't be able to store UTF-8, but
it does mean you'd pay a conversion cost when a UTF-8 string crosses the
boundary into Foundation or ICU.

> If so, is that a solvable problem? Could one choose by typealias or a
> compiler flag which default storage they wanted?

The latter *might* be possible, but I'd very much rather not.

>> - If we have a way to get at a `String`'s code units, we need a concrete 
>> type in
>>  which to express them in the API of `String`, which is a concrete type
>> - If String needs to be able to represent UTF-32, presumably the code units 
>> need
>>  to be `UInt32`.
>> - Not supporting UTF-32-encoded text seems like one reasonable design choice.
>> - Maybe we can allow UTF-8 storage in `String` and expose its code units as
>>  `UInt16`, just as we would for Latin-1.
>> - Supporting only UTF-16-subset encodings would imply that `String` indices 
>> can
>>  be serialized without recording the `String`'s underlying encoding.
>
> I suppose you could be clever on 64-bit platforms by stealing some
> bits to indicate the encoding…  not that I recommend that :D

There's nothing particularly tricky about that; it's absolutely
possible and the sort of thing we'd consider.

>> ### Do we need a type-erasable base protocol for UnicodeEncoding?
>> 
>> UnicodeEncoding has an associated type, but it may be important to be able to
>> traffic in completely dynamic encoding values, e.g. for “tell me the most
>> efficient encoding for this string.”
>
> Generalized Existentials 
> tis but happiness by another name
> For we who live 
> in The Land of Protocols and Faeries
>
>> 
>> ### Should there be a string “facade?”
>> 
>> One possible design alternative makes `Unicode` a vehicle for expressing
>> the storage and encoding of code units, but does not attempt to give it an 
>> API
>> appropriate for `String`.  Instead, string APIs would be provided by a 
>> generic
>> wrapper around an instance of `Unicode`:
>> 
>> ```swift
>> struct StringFacade : BidirectionalCollection {
>> 
>>  // ...APIs for high-level string processing here...
>> 
>>  var unicode: U // access to lower-level unicode details
>> }
>> 
>> typealias String = StringFacade
>> typealias Substring =

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Tue Jan 24 2017, Chris Eidhof  wrote:

> I agree that being able to implement parsers in a nice way can be a huge
> step forward in being really good at string processing.
>
> There are a couple of possibilities that come to mind directly:
>
> 1. Build parsers right into the language (like Perl 6 grammars)
> 2. Provide a parser combinator language (e.g.
> https://github.com/davedufresne/SwiftParsec).
> 3. Rely on external tools like bison/yacc/etc.
> 4. Make it easy for people to write hand-written parsers (e.g. by providing
> an NSScanner alternative).
>
> Some obvious drawbacks of each approach:
>
> 1. Lots of work, probably hard to get right?
> 2. Only way to do this, afaik, is using lots of functional programming
> which might scare people off. Also probably it's hard to get performance as
> fast as 1.

No, you don't need to use lots of
FP. 
https://github.com/apple/swift/blob/master/test/Prototypes/PatternMatching.swift#L359
is a counterexample.

> 3. No clear integrated way to do this 
> 4. You still have to know how to write a parser.
>
> I would think that 4. would be a good step forward, and 1/2 would
> definitely benefit from this.
>
> Also, I'd love to have this functionality on sequence/collection types,
> rather than Strings. 

Yes, that's the plan.

> For example, it can be tremendously helpful to parse a binary format
> using proper parsers. Or maybe you would want to use an event-driven
> XML parser as "tokenizer" and parse that. Plenty of cool
> possibilities.
>
> On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado 
>> wrote:
>>
>> Taken from NSHipster :
>>
>>> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has
>>> the most long-winded and byzantine regular expression interface you’re ever
>>> likely to come across.
>>
>>
>> There is no way to achieve the goal of being better at string processing
>> than Perl without regular expressions being addressed. It just should not
>> be ignored.
>>
>>
>>
>> We’re certainly not ignoring the importance of regexes. But if there’s a
>> key takeaway from your experiences with NSRegularExpression, it’s that a
>> good regex implementation matters, a lot. That’s why we don’t want to rush
>> one in alongside the rest of the overhaul of String. Instead, we should
>> take our time to make it really great, and building on a solid foundation
>> of a good String API that’s already in place should help ensure that.
>>
>>
>> I do think that there's some danger to focusing too narrowly on regular
>> expressions as they appear in languages today. I think the industry has
>> largely moved on to fully-structured formats that require proper parsing
>> beyond what traditional regexes can handle. The decades of experience with
>> Perl shows that making regexes too easy to use without an easy ramp up to
>> more sophisticated string processing leads to people cutting corners trying
>> to make regex-based designs kind-of work. The Perl 6 folks recognized this
>> and developed their "regular expression" support into something that
>> supported arbitrary grammars; I think we'd do well to start at that level
>> by looking at what they've done.
>>
>> -Joe
>>
>>
>> I fully agree. I think we could learn something from Perl 6 grammars. As
>> PCREs are to languages without regex, Perl 6 grammars are to languages with
>> PCREs.
>>
>> A lot of really crappy user interfaces and bad tools come down to
>> half-assed parsers; maybe we can do better? (Another argument against
>> rushing it).
>>
>>
>> Russ
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Ben Cohen via swift-evolution 

> On Jan 24, 2017, at 12:35 AM, Russ Bishop  wrote:
> 
>> ## Open Questions
>> 
>> ### Must `String` be limited to storing UTF-16 subset encodings?
>> 
>> - The ability to handle `UTF-8`-encoded strings (models of `Unicode`) is not 
>> in
>> question here; this is about what encodings must be storable, without
>> transcoding, in the common currency type called “`String`”.
>> - ASCII, Latin-1, UCS-2, and UTF-16 are UTF-16 subsets.  UTF-8 is not.
> 
> Depending on who you believe UTF-8 is the encoding of ~65-88% of all text 
> content transmitted over the web. JSON and XML represent the lion’s share of 
> REST and non-REST APIs in use and both are almost exclusively transmitted as 
> UTF-8. As you point out with extendedASCII, a lot of markup and structure is 
> ASCII even if the content is not so UTF-8 represents a significant size 
> savings even on Chinese/Japanese web pages that require 3 bytes to represent 
> many characters (the savings on markup overwhelming the loss on textual 
> content).

Right – unfortunately these conversations when we’ve had them start with solid 
data (like 
https://w3techs.com/technologies/history_overview/character_encoding/ms/y 
 – 
though note this data tells you nothing about what proportion of UTF8 would be 
better held in memory as Latin1 or UTF16), but then descends into hand-wavy 
“utf8 is faster because tags” :) I’d love to see some empirical data on this, 
there must be some out there. It’s no small undertaking to produce it though.

The Java folks did some research about the speedup gains from compacting down 
to Latin1 where possible for their implementation 
(http://openjdk.java.net/jeps/254). But their hands were presumably partly tied 
by needing to preserve random access into UTF16 so I don’t know if they really 
considered/benched UTF8, and the detail about the exact nature of the corpus of 
data they tested on appears scant ("a collection of over 950 heap dumps from a 
variety of different Oracle software applications using Java”) unless there are 
some more in-depth papers available I haven’t found.

> Any model that makes using UTF-8 backed Strings difficult or cumbersome to 
> use can have a negative performance and memory impact. I don’t have a good 
> idea of the actual cost but it might be worth doing some test to determine 
> that.
> 

A UTF8String type that a developer chooses to use explicitly for performance 
reasons oughtn’t to be cumbersome from the perspective of using much of the 
standard library, which will be implemented mostly generically on Unicode or 
Collection. The question is, will it be a problem that creators of UTF8String 
will find themselves needing to convert to regular String often when passing 
values into an API implemented in terms of String. This isn’t really something 
we can test easily – it can only be determined in the field, based on what APIs 
those users find themselves using. My instinct is that it won’t be a big 
problem – that the set of people needing to hold UTF8 for performance doesn’t 
overlap much with the set of people needing to pass those strings into 
higher-level libraries (at least on the performance-critical path of their 
code), as long as we provide enough batteries-included features on String. But 
that’s not an evidence-based notion, just a hope.

> Is NSString interop the only reason to not just use UTF-8 as the default 
> storage? If so, is that a solvable problem? Could one choose by typealias or 
> a compiler flag which default storage they wanted?
> 

Not just NSString interop – ICU interop as well, which is very important given 
we rely on ICU to implement much of our Unicode functionality.


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

Re: [swift-evolution] String Comparison

2017-01-24 Thread Dave Abrahams via swift-evolution 

on Tue Jan 24 2017, Xiaodi Wu  wrote:

> I agree that there are refinements to operators that are needed, such as
> the ability to pick which ones to import and more flexibility in shadowing
> them, etc. But I think that's a whole nother discussion, and I rather think
> that string comparison is a distinctly poor use case for it. An operator is
> really tailored to do one unambiguous operation with two arguments. Here,
> there's more than one operation when it comes to string comparison and
> therefore multiple arguments. Why try to fit a square peg into a round
> hole? It's already possible to do what you suggest with ordinary function
> names, so what's different here seems to come down to new syntax that IMO
> should be designed separately in the context of operators, not really
> something to do with strings.

+1

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

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

2017-01-24 Thread Jose Cheyo Jimenez via swift-evolution 

> On Jan 24, 2017, at 8:31 AM, Daniel Dunbar  wrote:
> 
>> 
>> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> Hi Daniel, 
>> 
>> I think this is an excellent idea! This would also solve the “local only” 
>> packages problem. 
>> http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager
>>  
>> 
>> 
>> By treating the git repo still as a single package, we can then just allow 
>> local dependencies that live somewhere in the repo. 
>> 
>> let package = Package(
>> name: “myMainPackage",
>> dependencies: [
>>  .Package(url: “./allMyLocalPackages/packageOne/“), // don’t 
>> have to specify version because it is inherited from main package. 
>>  .Package(url: “./allMyLocalPackages/packageTwo/“),
>>  .Package(url: “./allMyLocalPackages/packageThree/“),
>>   ]
>> )
>> 
>> 
>> I think this would lower the scope of the proposal and it would address the 
>> issue of being able to split up a mono repo. 
>> 
>> Should I propose this as an alternative or collaborate on the draft that you 
>> have?
> 
> I'm not exactly sure what change you are proposing, can you elaborate? What 
> is "allMyLocalPackages" in your email?
> 
>  - Daniel

That is just a directory that it is not named sources. 

After reading the road map. I think what I am referring to here is something 
along the line of 
– Overriding Package Conventions
– Support for Top-of-Tree

But not quite Multi-package repository because I just want to be to able to 
have multiple packages in one repo but not necessary have them exposed as 
individual sub packages. 

This is the same use case as the above stackoverflow multiple local packages 
question. 

> 
>> I have a very specific example where I want to be able to split up a repo so 
>> I can test them together on CI. 
>> https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21
>>  
>> 
>> 
>> 
>> Thank you. 
>> 
>> 
>>> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar via swift-evolution 
>>> > wrote:
>>> 
 
 On Nov 12, 2016, at 9:43 PM, Russ Bishop > wrote:
 
 
> On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev 
> > wrote:
> 
> Hi all,
> 
> I'm reposting a request for feedback on my proposal for extending SwiftPM 
> to support multiple packages inside one repository (i.e. "monorepo" 
> support, although it is a misnomer in this use case).
> https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/-swiftpm-multi-package-repos.md
>  
> 
> 
> I would like to move this proposal forward so we can start on an 
> implementation, even if we need to refine it over time, but I was hoping 
> to get at least some concrete feedback first.
> 
> Thanks,
> - Daniel
 
 
 It seems like you’re going through contortions to deal with arbitrary 
 directory layouts and some odd consequences fall out of that decision. Not 
 being able to deterministically detect non-unique sub-packages is one. 
 
 Why not just require a top-level Package.swift that explicitly specifies 
 the sub-packages? The name for the sub-package should be in the main 
 package manifest. You’d gain the ability to import all the sub-packages in 
 one go; importing the root package without any sub-packages specified 
 automatically imports all sub-packages. This also allows library authors 
 to organize a library into sub-packages later without breakage. Come up 
 with a convention, e.g. a sub-package is in “/subpackageName” but allow 
 overriding that default. That allows reorganization if needed but the 
 convention should work for most libraries.
>>> 
>>> Mostly because I am concerned this doesn't scale well to *very* large 
>>> repositories, in which commits to that file would be "contentious" (in the 
>>> lock contention sense, not subject to debate sense). Of course, this 
>>> argument is a little bogus as the current proposal doesn't scale that great 
>>> either since we have to discover the packages (although I believe we can 
>>> probably do a good job of caching this information).
>>> 
>>> It certainly would simplify the implementation & proposal to have this.
>>> 
>>> The other reason is it is yet another thing for

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Freak Show via swift-evolution 
Am I the only one who finds this incredibly ugly and hard to read?

This is more or less solved by inject:into: idiom.  There is no reason for 
inout for this particular problem.


> On Jan 24, 2017, at 06:43, Gwendal Roué via swift-evolution 
>  wrote:
> 
> But what if we stop fighting? Isn't the following code the correct version of 
> Chris's vision ?
> 
> extension Sequence {
> func reduce(mutating result: inout A, _ combine: (inout A, 
> Iterator.Element) -> ()) {
> for element in self {
> combine(, element)
> }
> }
> }
> 
> extension Sequence where Iterator.Element: Equatable {
> func uniq() -> [Iterator.Element] {
> var result: [Iterator.Element] = [] // meh
> reduce(mutating: ) { (result: inout [Iterator.Element], 
> element) in
> if result.last != element {
> result.append(element)
> }
> }
> return result
> }
> }
> 
> let x = [1, 1, 2, 3]
> x.uniq() // [1, 2, 3]

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

Re: [swift-evolution] [Discussion] mailing list alternative

2017-01-24 Thread thislooksfun via swift-evolution 
(Sending this again because the first was accidentally offlist. Stupid reply-to 
headers.)

+1 for Discourse from me as well.

As for making a Swift-based site, server libraries do exist (Perfect, Vapor, 
Kitura, etc.), but afaik there is currently no built-in server support yet.

-thislooksfun (tlf)

> On Jan 23, 2017, at 6:53 PM, Ethin Probst via swift-evolution 
>  wrote:
> 
> We will, but we can't do any rewriting of anything until Swifts server
> library is up and running, which I believe it is not (feel free to
> correct me if I am wrong).
> I'll go a little further and give a +4 for discourse. Or anything
> else. My email is filled with a total of 13808 e-mails. 141 of those
> are from the swift-evolution mailing list and 52 of those are from the
> swift-users one, for a total of 193 e-mails. Do you think I'm willing
> to browse all of those to determine what's going on? Hell no! A forum
> would allow us to get the most germane and contemporary dialogue for
> all the members. Why not just forumize all of the mailing lists, and
> not just this one? Make it use only one instance of the forum software
> and make separate categories--or forums, even--for each list so that
> it's all rationalized. It would save people a lot of headaches trying
> to remember URLs.
> 
> On 1/23/17, David Sweeris via swift-evolution  
> wrote:
>> 
>>> On Jan 23, 2017, at 09:59, Joshua Alvarado via swift-evolution
>>>  wrote:
>>> 
>>> It will be painted! ;)
>>> 
>>> So far we have:
>>> +2 Disclosure
>>> +1 Slack
>>> +1 Issue tracker
>>> 
>>> Let's really get everyone's opinions and see if we can get this rock
>>> rolling towards a better solution. Of course it will be Apple's choice in
>>> the end but we can give a voice on the matter to show we do care about
>>> moving over.
>> 
>> I'd even be happy with phpBB. I wonder if there's an issue tracker plugin
>> yet?
>> 
>> Whatever we use, we'll have to rewrite it in Swift, though, since this is
>> supposed to be a language for server apps.
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> ___
> 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] Reduce with inout

2017-01-24 Thread Xiaodi Wu via swift-evolution 
Yes, Matthew, I agree with you exactly on this. It's tricky. `copyOf` isn't
ideal at all, but `mutating` is potentially misleading. Ah the difficulties
of naming things.


On Tue, Jan 24, 2017 at 09:15 Matthew Johnson 
wrote:

> On Jan 24, 2017, at 8:12 AM, Chris Eidhof  wrote:
>
> But if we want to add "copyOf" we should do that to every method that
> takes a struct? Also, what if you pass in an object?
>
> I see the concern, but I don't think adding `copyOf` will increase
> clarity. That said, I'm open to suggestions.
>
>
> I’m not really trying to advocate for “copyOf”.  I think we should really
> have something more concise in a case like this.  My main point is that
> just using `mutating` is inaccurate and therefore probably not the right
> solution.
>
> Your question about passing in an object (I assume you mean a reference
> type here) is a good one.  In an ideal world that would probably not be
> allowed as it doesn’t really make sense to replace the reference during
> reduction.  Unfortunately I don’t think we have a way to prevent that at
> the moment.
>
>
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  wrote:
>
> It's only verbose if the words aren't needed! The shortest way to describe
> something with sufficient accuracy can never be verbose, let alone
> undesirable, and I highly agree with this concern. We already have names of
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
>
>
> I mostly agree with this Xiaodi, but I also think that commonly known and
> frequently used methods like `reduce` deserve to be as concise as
> possible.  That is less a concern with less common and less frequently used
> signatures.
>
>
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPad
>
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I've thought about it for a few days, and really like
> `reduce(mutating:_)`.
>
>
> I'm not a fan of this.  It reads in a way that makes it seem like the
> parameter should be inout, but it isn't.  A variation of reduce where the
> initial value parameter *is* inout is perfectly sensible (whether or not we
> want it in the standard library).  With that in mind, I don't think we
> should use this name.
>
> Unfortunately I don't have a better suggestion.  I think it was Brent who
> suggested "mutatingCopyOf" which is more accurate, but also undesirably
> verbose.
>
> I've updated the PR, and am now happy for this to go into review.
>
> https://github.com/apple/swift-evolution/pull/587
>
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>
>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>
>
>
>
> --
> Chris Eidhof
>
> ___
> 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
>
>
>
>
> --
> Chris Eidhof
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

2017-01-24 Thread Daniel Dunbar via swift-evolution 

> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez  wrote:
> 
> Hi Daniel, 
> 
> I think this is an excellent idea! This would also solve the “local only” 
> packages problem. 
> http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager
>  
> 
> 
> By treating the git repo still as a single package, we can then just allow 
> local dependencies that live somewhere in the repo. 
> 
> let package = Package(
> name: “myMainPackage",
> dependencies: [
>   .Package(url: “./allMyLocalPackages/packageOne/“), // don’t 
> have to specify version because it is inherited from main package. 
>   .Package(url: “./allMyLocalPackages/packageTwo/“),
>   .Package(url: “./allMyLocalPackages/packageThree/“),
>]
> )
> 
> 
> I think this would lower the scope of the proposal and it would address the 
> issue of being able to split up a mono repo. 
> 
> Should I propose this as an alternative or collaborate on the draft that you 
> have?

I'm not exactly sure what change you are proposing, can you elaborate? What is 
"allMyLocalPackages" in your email?

 - Daniel

> I have a very specific example where I want to be able to split up a repo so 
> I can test them together on CI. 
> https://github.com/exercism/xswift/commit/4935b94c78a69f88b42c7a518c16e0c8b4f6fe8d#diff-37ca2dd15ca0f6b1b49e78db084ef5b9R21
>  
> 
> 
> 
> Thank you. 
> 
> 
>> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Nov 12, 2016, at 9:43 PM, Russ Bishop >> > wrote:
>>> 
>>> 
 On Nov 12, 2016, at 1:02 PM, Daniel Dunbar via swift-build-dev 
 > wrote:
 
 Hi all,
 
 I'm reposting a request for feedback on my proposal for extending SwiftPM 
 to support multiple packages inside one repository (i.e. "monorepo" 
 support, although it is a misnomer in this use case).
 https://github.com/ddunbar/swift-evolution/blob/multi-package-repos/proposals/-swiftpm-multi-package-repos.md
  
 
 
 I would like to move this proposal forward so we can start on an 
 implementation, even if we need to refine it over time, but I was hoping 
 to get at least some concrete feedback first.
 
 Thanks,
 - Daniel
>>> 
>>> 
>>> It seems like you’re going through contortions to deal with arbitrary 
>>> directory layouts and some odd consequences fall out of that decision. Not 
>>> being able to deterministically detect non-unique sub-packages is one. 
>>> 
>>> Why not just require a top-level Package.swift that explicitly specifies 
>>> the sub-packages? The name for the sub-package should be in the main 
>>> package manifest. You’d gain the ability to import all the sub-packages in 
>>> one go; importing the root package without any sub-packages specified 
>>> automatically imports all sub-packages. This also allows library authors to 
>>> organize a library into sub-packages later without breakage. Come up with a 
>>> convention, e.g. a sub-package is in “/subpackageName” but allow overriding 
>>> that default. That allows reorganization if needed but the convention 
>>> should work for most libraries.
>> 
>> Mostly because I am concerned this doesn't scale well to *very* large 
>> repositories, in which commits to that file would be "contentious" (in the 
>> lock contention sense, not subject to debate sense). Of course, this 
>> argument is a little bogus as the current proposal doesn't scale that great 
>> either since we have to discover the packages (although I believe we can 
>> probably do a good job of caching this information).
>> 
>> It certainly would simplify the implementation & proposal to have this.
>> 
>> The other reason is it is yet another thing for people to maintain (and 
>> remember the syntax for). Most repos are small enough that I think the 
>> current proposal would perform fine and have a tendency to do what people 
>> might naively expect (even if they didn't really think about why). On the 
>> other hand, this file is likely to be quite static, so I'm not sure that is 
>> a very important issue.
>> 
>> I was already on the fence on this, but I hadn't considered the benefits you 
>> mention of allowing import of the package w/ no sub package specifier to 
>> mean import of all sub-packages. That tips me a little more towards thinking 
>> maybe a better proposal is to KISS and require this in some root file 
>> (whether or not that

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Chris Eidhof via swift-evolution 
Hey Matthew,

Do you have an example of doing parser combinators without FP? I'd be very
interest

On Tue, Jan 24, 2017 at 4:52 PM, Matthew Johnson 
wrote:

>
> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I agree that being able to implement parsers in a nice way can be a huge
> step forward in being really good at string processing.
>
> There are a couple of possibilities that come to mind directly:
>
> 1. Build parsers right into the language (like Perl 6 grammars)
> 2. Provide a parser combinator language (e.g. https://github.com/
> davedufresne/SwiftParsec).
> 3. Rely on external tools like bison/yacc/etc.
> 4. Make it easy for people to write hand-written parsers (e.g. by
> providing an NSScanner alternative).
>
> Some obvious drawbacks of each approach:
>
> 1. Lots of work, probably hard to get right?
> 2. Only way to do this, afaik, is using lots of functional programming
> which might scare people off. Also probably it's hard to get performance as
> fast as 1.
>
>
> FWIW, it is quite possible to do things very similar to parser combinators
> without functional programming.  What you need is a way to create and
> compose small parser fragments, ideally an EDSL approaching something like
> EBNF that allows users to build a grammar out of the parser fragments, and
> a way to execute / interpret the resulting grammar during parsing.
>

I'd love to see this. Do you mean "possible today" or "it would be
possible"?

One really big thing that I took away learning parser combinators is that
grammars are composable, whereas parsers themselves are not. Parser
combinators express grammars.

For example, when you have a Swift parser available, and you want to
"embed" it inside a Markdown parser, that's hard to do. Whereas composing
the Markdown grammar with the Swift grammar is a lot easier.

It'd be nice to have that composability.

Chris


>
> The functional approach would not be the most idiomatic approach in Swift
> and as you note, it probably wouldn’t have the performance a more idiomatic
> approach could achieve (too much copying).
>
> My intuition is that a hybrid 1 / 2 approach might be best: do as much as
> possible in the library and let the design drive new language enhancements
> where necessary.
>
> 3. No clear integrated way to do this
> 4. You still have to know how to write a parser.
>
> I would think that 4. would be a good step forward, and 1/2 would
> definitely benefit from this.
>
> Also, I'd love to have this functionality on sequence/collection types,
> rather than Strings. For example, it can be tremendously helpful to parse a
> binary format using proper parsers. Or maybe you would want to use an
> event-driven XML parser as "tokenizer" and parse that. Plenty of cool
> possibilities.
>
> On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado 
>> wrote:
>>
>> Taken from NSHipster :
>>
>>> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa
>>> has the most long-winded and byzantine regular expression interface you’re
>>> ever likely to come across.
>>
>>
>> There is no way to achieve the goal of being better at string processing
>> than Perl without regular expressions being addressed. It just should not
>> be ignored.
>>
>>
>>
>> We’re certainly not ignoring the importance of regexes. But if there’s a
>> key takeaway from your experiences with NSRegularExpression, it’s that a
>> good regex implementation matters, a lot. That’s why we don’t want to rush
>> one in alongside the rest of the overhaul of String. Instead, we should
>> take our time to make it really great, and building on a solid foundation
>> of a good String API that’s already in place should help ensure that.
>>
>>
>> I do think that there's some danger to focusing too narrowly on regular
>> expressions as they appear in languages today. I think the industry has
>> largely moved on to fully-structured formats that require proper parsing
>> beyond what traditional regexes can handle. The decades of experience with
>> Perl shows that making regexes too easy to use without an easy ramp up to
>> more sophisticated string processing leads to people cutting corners trying
>> to make regex-based designs kind-of work. The Perl 6 folks recognized this
>> and developed their "regular expression" support into something that
>> supported arbitrary grammars; I think we'd do well to start at that level
>> by looking at what they've done.
>>
>> -Joe
>>
>>
>> I fully agree. I think we could learn something from Perl 6 grammars. As
>> PCREs are to languages

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I agree that being able to implement parsers in a nice way can be a huge step 
> forward in being really good at string processing.
> 
> There are a couple of possibilities that come to mind directly:
> 
> 1. Build parsers right into the language (like Perl 6 grammars)
> 2. Provide a parser combinator language (e.g. 
> https://github.com/davedufresne/SwiftParsec 
> ). 
> 3. Rely on external tools like bison/yacc/etc.
> 4. Make it easy for people to write hand-written parsers (e.g. by providing 
> an NSScanner alternative).
> 
> Some obvious drawbacks of each approach:
> 
> 1. Lots of work, probably hard to get right?
> 2. Only way to do this, afaik, is using lots of functional programming which 
> might scare people off. Also probably it's hard to get performance as fast as 
> 1.

FWIW, it is quite possible to do things very similar to parser combinators 
without functional programming.  What you need is a way to create and compose 
small parser fragments, ideally an EDSL approaching something like EBNF that 
allows users to build a grammar out of the parser fragments, and a way to 
execute / interpret the resulting grammar during parsing.  

The functional approach would not be the most idiomatic approach in Swift and 
as you note, it probably wouldn’t have the performance a more idiomatic 
approach could achieve (too much copying).

My intuition is that a hybrid 1 / 2 approach might be best: do as much as 
possible in the library and let the design drive new language enhancements 
where necessary.

> 3. No clear integrated way to do this
> 4. You still have to know how to write a parser.
> 
> I would think that 4. would be a good step forward, and 1/2 would definitely 
> benefit from this.
> 
> Also, I'd love to have this functionality on sequence/collection types, 
> rather than Strings. For example, it can be tremendously helpful to parse a 
> binary format using proper parsers. Or maybe you would want to use an 
> event-driven XML parser as "tokenizer" and parse that. Plenty of cool 
> possibilities.
> 
> On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution 
> > wrote:
> 
>> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Jan 23, 2017, at 7:49 AM, Joshua Alvarado > wrote:
 
 Taken from NSHipster :
 Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has 
 the most long-winded and byzantine regular expression interface you’re 
 ever likely to come across.
 
 There is no way to achieve the goal of being better at string processing 
 than Perl without regular expressions being addressed. It just should not 
 be ignored. 
>>> 
>>> 
>>> We’re certainly not ignoring the importance of regexes. But if there’s a 
>>> key takeaway from your experiences with NSRegularExpression, it’s that a 
>>> good regex implementation matters, a lot. That’s why we don’t want to rush 
>>> one in alongside the rest of the overhaul of String. Instead, we should 
>>> take our time to make it really great, and building on a solid foundation 
>>> of a good String API that’s already in place should help ensure that.
>> 
>> I do think that there's some danger to focusing too narrowly on regular 
>> expressions as they appear in languages today. I think the industry has 
>> largely moved on to fully-structured formats that require proper parsing 
>> beyond what traditional regexes can handle. The decades of experience with 
>> Perl shows that making regexes too easy to use without an easy ramp up to 
>> more sophisticated string processing leads to people cutting corners trying 
>> to make regex-based designs kind-of work. The Perl 6 folks recognized this 
>> and developed their "regular expression" support into something that 
>> supported arbitrary grammars; I think we'd do well to start at that level by 
>> looking at what they've done.
>> 
>> -Joe
>> 
> 
> I fully agree. I think we could learn something from Perl 6 grammars. As 
> PCREs are to languages without regex, Perl 6 grammars are to languages with 
> PCREs. 
> 
> A lot of really crappy user interfaces and bad tools come down to half-assed 
> parsers; maybe we can do better? (Another argument against rushing it).
> 
> 
> Russ
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
>

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Matthew Johnson via swift-evolution 

> On Jan 24, 2017, at 8:12 AM, Chris Eidhof  wrote:
> 
> But if we want to add "copyOf" we should do that to every method that takes a 
> struct? Also, what if you pass in an object?
> 
> I see the concern, but I don't think adding `copyOf` will increase clarity. 
> That said, I'm open to suggestions.

I’m not really trying to advocate for “copyOf”.  I think we should really have 
something more concise in a case like this.  My main point is that just using 
`mutating` is inaccurate and therefore probably not the right solution.

Your question about passing in an object (I assume you mean a reference type 
here) is a good one.  In an ideal world that would probably not be allowed as 
it doesn’t really make sense to replace the reference during reduction.  
Unfortunately I don’t think we have a way to prevent that at the moment.

> 
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  > wrote:
> It's only verbose if the words aren't needed! The shortest way to describe 
> something with sufficient accuracy can never be verbose, let alone 
> undesirable, and I highly agree with this concern. We already have names of 
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.

I mostly agree with this Xiaodi, but I also think that commonly known and 
frequently used methods like `reduce` deserve to be as concise as possible.  
That is less a concern with less common and less frequently used signatures.

> 
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> I've thought about it for a few days, and really like `reduce(mutating:_)`.
> 
> I'm not a fan of this.  It reads in a way that makes it seem like the 
> parameter should be inout, but it isn't.  A variation of reduce where the 
> initial value parameter *is* inout is perfectly sensible (whether or not we 
> want it in the standard library).  With that in mind, I don't think we should 
> use this name.  
> 
> Unfortunately I don't have a better suggestion.  I think it was Brent who 
> suggested "mutatingCopyOf" which is more accurate, but also undesirably 
> verbose.
> 
>> I've updated the PR, and am now happy for this to go into review.
>> 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof >> > wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other suggestions?
>>> 
>>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop >> > wrote:
>>> -- 
>>> Chris Eidhof
>> 
>> 
>> Sorry for the derail!
>> 
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
>> we will copy the value now but mutate it later.
>> 
>> 
>> Some alternatives:
>> 
>> reduce(forMutating:_:) { }
>> 
>> reduce(forInout:_:) { }
>> 
>> reduce(initial:_:) { }
>> 
>> reduce(copying:mutate:) { }
>> 
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>> 
>> 
>> 
>> It should definitely be some form of reduce. 
>> 
>> Russ
>> 
>> 
>> 
>> -- 
>> Chris Eidhof
>> ___
>> 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 
> 
> 
> 
> 
> -- 
> Chris Eidhof

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

Re: [swift-evolution] Generic Subscripts

2017-01-24 Thread Thorsten Seitz via swift-evolution 


> Am 23.01.2017 um 18:26 schrieb Gwendal Roué :
> 
>> Where generic subscripts are concerned, there are a couple of different 
>> things to express:
>> - Generic parameter  (I can understand various co-ordinates for the data)
>> - Generic return type (I can construct your preferred representation of 
>> the data)
>> - Generic setter type (I can set the data using various compatible 
>> types):
> 
> I think all of these should be expressed with a single generic signature 
> on the subscript itself. The element type passed to the setter and 
> returned from the getter should be the same IMO, otherwise it’s not clear 
> how it will work.
 
 Yes.  It's quite important that any particular subscript reference is 
 still a single consistent entity, even if generic; we would not want, say, 
 a read-modify-write access to be able to somehow invoke the getter and 
 setter at different generic arguments, or to traffic in different element 
 types.
 
 I'm also not sure we'd ever want the element type to be inferred from 
 context like this.  Generic subscripts as I see it are about being generic 
 over *indexes*, not somehow about presenting a polymorphic value.
>>> 
>>> This is a consequence of your vision of subscript. If interesting, it is 
>>> also limiting for no real purpose.
>>> 
>>> As the developer of a Swift database library, I'd like to offer a better 
>>> API than the following:
>>> 
>>> // Current state of affairs
>>> let name: String = row.value(named: "name")
>>> let bookCount: Int = row.value(named: "bookCount")
>>> let hasBooks: Bool = row.value(named: "bookCount")
>>> 
>>> Instead, I wish I could offer GRDB.swift would let its users write:
>>> 
>>> // With improved subscripts
>>> let name: String = row["name"]
>>> let bookCount: Int = row["bookCount"]
>>> let hasBooks: Bool = row["bookCount"]
>>> 
>>> And this requires genericity on return type.
>> 
>> This is not typesafe at all if the type does not depend on the argument. I'd 
>> prefer keys carrying the meta information of their respective database 
>> column keeping the whole API typesafe.
> 
> As long as your personal preference has no impact on return-type genericity 
> subscripts adoption, I'm fine with it :-)

No problem with that :-)

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Gwendal Roué via swift-evolution 
I think you're all fighting against the language, and especially against 
`inout`. Because you try to copy and then mutate a value, instead of mutating 
it right away.

I totally understand why: `inout` requires variable declared `var`, and the 
compiler won't auto-generate it for us. We try to avoid polluting our code with 
those extra `var` variables. They make code look messy.

But what if we stop fighting? Isn't the following code the correct version of 
Chris's vision ?

extension Sequence {
func reduce(mutating result: inout A, _ combine: (inout A, 
Iterator.Element) -> ()) {
for element in self {
combine(, element)
}
}
}

extension Sequence where Iterator.Element: Equatable {
func uniq() -> [Iterator.Element] {
var result: [Iterator.Element] = [] // meh
reduce(mutating: ) { (result: inout [Iterator.Element], element) 
in
if result.last != element {
result.append(element)
}
}
return result
}
}

let x = [1, 1, 2, 3]
x.uniq() // [1, 2, 3]

Yes, the extra `var` variable in the implementation of `uniq` is awful. But 
that's a limitation of `inout`. Not a limitation of your imagination when you 
try to find a good name for your method.

I'd suggest us to think about improving Swift so that it starts generating 
those extra `var` variables for us. It would then give:

func f(i: inout Int) { ... }
f(1) // OK, even if mutated result is lost
let x: Int = 2
f(x) // OK, even if mutated result is lost

And reduce(mutating:) would get rid of the extra var:

extension Sequence {
func reduce(mutating result: inout A, _ combine: (inout A, 
Iterator.Element) -> ()) -> A {
for element in self {
combine(, element)
}
return result
}
}

extension Sequence where Iterator.Element: Equatable {
func uniq() -> [Iterator.Element] {
return reduce(mutating: []) { (result: inout [Iterator.Element], 
element) in
if result.last != element {
result.append(element)
}
}
}
}

Gwendal


> Le 24 janv. 2017 à 15:12, Chris Eidhof via swift-evolution 
>  a écrit :
> 
> But if we want to add "copyOf" we should do that to every method that takes a 
> struct? Also, what if you pass in an object?
> 
> I see the concern, but I don't think adding `copyOf` will increase clarity. 
> That said, I'm open to suggestions.
> 
> On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  > wrote:
> It's only verbose if the words aren't needed! The shortest way to describe 
> something with sufficient accuracy can never be verbose, let alone 
> undesirable, and I highly agree with this concern. We already have names of 
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
> 
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPad
> 
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> I've thought about it for a few days, and really like `reduce(mutating:_)`. 
> 
> I'm not a fan of this.  It reads in a way that makes it seem like the 
> parameter should be inout, but it isn't.  A variation of reduce where the 
> initial value parameter *is* inout is perfectly sensible (whether or not we 
> want it in the standard library).  With that in mind, I don't think we should 
> use this name.  
> 
> Unfortunately I don't have a better suggestion.  I think it was Brent who 
> suggested "mutatingCopyOf" which is more accurate, but also undesirably 
> verbose.
> 
>> I've updated the PR, and am now happy for this to go into review.
>> 
>> https://github.com/apple/swift-evolution/pull/587 
>> 
>> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop > > wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof >> > wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Brent Royal-Gordon via swift-evolution 
> On Jan 23, 2017, at 9:59 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
>> You can do it, but it trades one semantic problem for a usability problem, 
>> without solving all the semantic problems: you end up with a.count + b.count 
>> == (a+b).count, sure, but you still don't satisfy the usual law of 
>> collections that (a+b).contains(b.first!) if b is non-empty, and now you've 
>> made it difficult to attach diacritics to base characters.
> 
> "Difficult".
> 
> What kind of processing would you suggest on a variable "b" in the expression 
> "\(a),\(b)" to ensure that the result can be split with a comma?

Use of the `extendedASCII` view to parse it. :^)

In all seriousness, though, maybe this just means you should be parsing at the 
`unicodeScalars` level or below when you're doing this kind of thing.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Chris Eidhof via swift-evolution 
But if we want to add "copyOf" we should do that to every method that takes
a struct? Also, what if you pass in an object?

I see the concern, but I don't think adding `copyOf` will increase clarity.
That said, I'm open to suggestions.

On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu  wrote:

> It's only verbose if the words aren't needed! The shortest way to describe
> something with sufficient accuracy can never be verbose, let alone
> undesirable, and I highly agree with this concern. We already have names of
> this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
>
> On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I've thought about it for a few days, and really like
>> `reduce(mutating:_)`.
>>
>>
>> I'm not a fan of this.  It reads in a way that makes it seem like the
>> parameter should be inout, but it isn't.  A variation of reduce where the
>> initial value parameter *is* inout is perfectly sensible (whether or not we
>> want it in the standard library).  With that in mind, I don't think we
>> should use this name.
>>
>> Unfortunately I don't have a better suggestion.  I think it was Brent who
>> suggested "mutatingCopyOf" which is more accurate, but also undesirably
>> verbose.
>>
>> I've updated the PR, and am now happy for this to go into review.
>>
>> https://github.com/apple/swift-evolution/pull/587
>>
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>>
>>
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>>
>> Not as a direct reply to Russ, but just to reiterate: to me, there are
>> two clear benefits of using the `inout` version of reduce:
>>
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>
>> Even if the compiler were to optimize the unnecessary copy of `return arr
>> + [el]` away, there are still a lot of other mutable methods that you might
>> want to use within the reduce closure. So I think the proposal is still
>> very valid even if the compiler optimizations would magically appear
>> tomorrow.
>>
>> To push this proposal forward a little bit, I'd like to come up with a
>> good name. It seems like we shouldn't overload `reduce`, but choose a
>> different name, so that we don't stress the typechecker. Any other
>> suggestions?
>>
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>> --
>> Chris Eidhof
>>
>>
>>
>> Sorry for the derail!
>>
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to
>> mean we will copy the value now but mutate it later.
>>
>>
>> Some alternatives:
>>
>> reduce(forMutating:_:) { }
>>
>> reduce(forInout:_:) { }
>>
>> reduce(initial:_:) { }
>>
>> reduce(copying:mutate:) { }
>>
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>>
>>
>>
>> It should definitely be some form of reduce.
>>
>> Russ
>>
>>
>>
>>
>> --
>> Chris Eidhof
>>
>> ___
>> 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
>>
>


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

Re: [swift-evolution] Reduce with inout

2017-01-24 Thread Xiaodi Wu via swift-evolution 
It's only verbose if the words aren't needed! The shortest way to describe
something with sufficient accuracy can never be verbose, let alone
undesirable, and I highly agree with this concern. We already have names of
this form, such as `FloatingPoint.init(signOf:magnitudeOf:)`.
On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I've thought about it for a few days, and really like
> `reduce(mutating:_)`.
>
>
> I'm not a fan of this.  It reads in a way that makes it seem like the
> parameter should be inout, but it isn't.  A variation of reduce where the
> initial value parameter *is* inout is perfectly sensible (whether or not we
> want it in the standard library).  With that in mind, I don't think we
> should use this name.
>
> Unfortunately I don't have a better suggestion.  I think it was Brent who
> suggested "mutatingCopyOf" which is more accurate, but also undesirably
> verbose.
>
> I've updated the PR, and am now happy for this to go into review.
>
> https://github.com/apple/swift-evolution/pull/587
>
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>
>
> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>
> Not as a direct reply to Russ, but just to reiterate: to me, there are two
> clear benefits of using the `inout` version of reduce:
>
> 1. The performance (currently discussed at length)
> 2. Readability (because we can use mutating methods on `inout` arguments).
>
> Even if the compiler were to optimize the unnecessary copy of `return arr
> + [el]` away, there are still a lot of other mutable methods that you might
> want to use within the reduce closure. So I think the proposal is still
> very valid even if the compiler optimizations would magically appear
> tomorrow.
>
> To push this proposal forward a little bit, I'd like to come up with a
> good name. It seems like we shouldn't overload `reduce`, but choose a
> different name, so that we don't stress the typechecker. Any other
> suggestions?
>
> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
> --
> Chris Eidhof
>
>
>
> Sorry for the derail!
>
> reduce(mutating:_:) { } is still my favorite; You can take mutating to
> mean we will copy the value now but mutate it later.
>
>
> Some alternatives:
>
> reduce(forMutating:_:) { }
>
> reduce(forInout:_:) { }
>
> reduce(initial:_:) { }
>
> reduce(copying:mutate:) { }
>
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
>
>
>
> It should definitely be some form of reduce.
>
> Russ
>
>
>
>
> --
> Chris Eidhof
>
> ___
> 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] Reduce with inout

2017-01-24 Thread Matthew Johnson via swift-evolution 


Sent from my iPad

> On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> I've thought about it for a few days, and really like `reduce(mutating:_)`.

I'm not a fan of this.  It reads in a way that makes it seem like the parameter 
should be inout, but it isn't.  A variation of reduce where the initial value 
parameter *is* inout is perfectly sensible (whether or not we want it in the 
standard library).  With that in mind, I don't think we should use this name.  

Unfortunately I don't have a better suggestion.  I think it was Brent who 
suggested "mutatingCopyOf" which is more accurate, but also undesirably verbose.

> I've updated the PR, and am now happy for this to go into review.
> 
> https://github.com/apple/swift-evolution/pull/587
> 
>> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
>> 
>>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>>> 
>>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>>> clear benefits of using the `inout` version of reduce:
>>> 
>>> 1. The performance (currently discussed at length)
>>> 2. Readability (because we can use mutating methods on `inout` arguments).
>>> 
>>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>>> [el]` away, there are still a lot of other mutable methods that you might 
>>> want to use within the reduce closure. So I think the proposal is still 
>>> very valid even if the compiler optimizations would magically appear 
>>> tomorrow.
>>> 
>>> To push this proposal forward a little bit, I'd like to come up with a good 
>>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>>> name, so that we don't stress the typechecker. Any other suggestions?
>>> 
>>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>>> -- 
>>> Chris Eidhof
>> 
>> 
>> Sorry for the derail!
>> 
>> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
>> we will copy the value now but mutate it later.
>> 
>> 
>> Some alternatives:
>> 
>> reduce(forMutating:_:) { }
>> 
>> reduce(forInout:_:) { }
>> 
>> reduce(initial:_:) { }
>> 
>> reduce(copying:mutate:) { }
>> 
>> // just kidding...
>> reduce(copyForLaterMutating:_:) { }
>> 
>> 
>> 
>> It should definitely be some form of reduce. 
>> 
>> Russ
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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] Compound Names For Enum Cases

2017-01-24 Thread David Hart via swift-evolution 
Ok, sounds logical. Might be worth adding that info to the proposal to make it 
clear how ambiguity plays out.

> On 24 Jan 2017, at 13:27, Xiaodi Wu  wrote:
> 
> I would imagine it would be logical to have it work just like it does now 
> with functions. If case bar is distinct, then that should still work, but if 
> bar is "overloaded," then case bar should be invalid for ambiguity. Seems 
> fine to me, shouldn't break any existing code and therefore we don't lose 
> anything.
> 
> 
> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution 
> > wrote:
> 
> 
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution 
> > wrote:
> 
>> We're not terribly principled about this right now with non-pattern 
>> declaration references. You can still reference an unapplied function by its 
>> base name alone without its labels, if it's unambiguous:
>> 
>> func foo(x: Int, y: Int) {}
>> 
>> let foo_x_y: (Int, Int) -> () = foo
>> 
>> so it'd be consistent to continue to allow the same in pattern references.
> 
> WRT ambiguity, do we loose the ability to pattern match on the naked case 
> name when two cases share the same base name?
> 
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> }
> 
> switch aFoo {
> case .bar: // matches both cases
> break
> }
> ___
> 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] Compound Names For Enum Cases

2017-01-24 Thread Xiaodi Wu via swift-evolution 
I would imagine it would be logical to have it work just like it does now
with functions. If case bar is distinct, then that should still work, but
if bar is "overloaded," then case bar should be invalid for ambiguity.
Seems fine to me, shouldn't break any existing code and therefore we don't
lose anything.


On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> We're not terribly principled about this right now with non-pattern
> declaration references. You can still reference an unapplied function by
> its base name alone without its labels, if it's unambiguous:
>
> func foo(x: Int, y: Int) {}
>
> let foo_x_y: (Int, Int) -> () = foo
>
>
> so it'd be consistent to continue to allow the same in pattern references.
>
>
> WRT ambiguity, do we loose the ability to pattern match on the naked case
> name when two cases share the same base name?
>
> enum Foo {
> case bar(a: Int)
> case bar(b: String)
> }
>
> switch aFoo {
> case .bar: // matches both cases
> break
> }
> ___
> 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] String Comparison (was: Strings in Swift 4)

2017-01-24 Thread Xiaodi Wu via swift-evolution 
I agree that there are refinements to operators that are needed, such as
the ability to pick which ones to import and more flexibility in shadowing
them, etc. But I think that's a whole nother discussion, and I rather think
that string comparison is a distinctly poor use case for it. An operator is
really tailored to do one unambiguous operation with two arguments. Here,
there's more than one operation when it comes to string comparison and
therefore multiple arguments. Why try to fit a square peg into a round
hole? It's already possible to do what you suggest with ordinary function
names, so what's different here seems to come down to new syntax that IMO
should be designed separately in the context of operators, not really
something to do with strings.
On Tue, Jan 24, 2017 at 03:13 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Breaking this into a different thread…
>
> One suggestion which I haven’t seen (maybe it is too crazy) is the idea of
> introducing shadowing of operators within a scope (similar to variables).
>
> Now this would need a TON of design work to make it actually work, but the
> gist would be:
>
> if blah == foo {
> //We can override/shadow the ‘<‘ operator within this
> scope as long as the signature is the same
> let (<) = String.comparisonOperation(case: .insensitive,
> locale: .current) //Here we grab a closure produced by a static function on
> String
>
> if a < b {  //Within this scope < will be case
> insensitive
> //Stuff
> }
> }
> //Outside of the scope, < is back to it’s lovable self
>
>
> Thoughts on the general idea?
>
> Thanks,
> Jon
>
>
> > I know you want to defer this for now, so feel free to set this part of
> the email aside, but here's a quick list of solutions I've ballparked:
> >
> > 1. Your "one operand carries the options" solution.
> >
> > 2. As I mentioned, do something that effectively overloads comparison
> operators to return them in a symbolic form. You're right about the
> ambiguity problem, though.
> >
> > 3. Like #2, but with slightly modified operators, e.g.:
> >
> >   if localized(fu &< br, case: .insensitive) { … }
> >
> > 4. Reintroduce something like the old `BooleanType` and have *all*
> comparisons construct a symbolic form that can be coerced to boolean. This
> is crazy, but actually probably useful in other places; I once experimented
> with constructing NSPredicates like this.
> >
> >   protocol BooleanProtocol { var boolValue: Bool { get } }
> >
> >   struct Comparison {
> >   var negated: Bool
> >   var sortOrder: SortOrder
> >   var left: Operand
> >   var right: Operand
> >
> >   func evaluate(_ actualSortOrder: SortOrder) -> Bool {
> >   // There's circularity problems here, because `==`
> would itself return a `Comparison`,
> >   // but I think you get the idea.
> >   return (actualSortOrder == sortOrder) != negated
> >   }
> >   }
> >   extension Comparison: BooleanProtocol {
> >   var boolValue: Bool {
> >   return evaluate(left.compared(to: right))
> >   }
> >   }
> >
> >   func < (lhs: ComparableType, rhs:
> ComparableType) -> Comparison {
> >   return Comparison(negated: false, sortOrder: .before,
> left: lhs, right: rhs)
> >   }
> >   func <= (lhs: ComparableType, rhs:
> ComparableType) -> Comparison {
> >   return Comparison(negated: true, sortOrder: .after, left:
> lhs, right: rhs)
> >   }
> >   // etc.
> >
> >   // Now for our special String comparison thing:
> >   func localized(_ expr: Comparison, case:
> StringCaseSensitivity? = nil, …) -> Bool {
> >   return expr.evaluate(expr.left.compare(expr.right, case:
> case, …))
> >   }
> >
> > 5. Actually add some all-new piece of syntax that allows you to add
> options to an operator. Bad part is that this is ugly and kind of weird;
> good part is that this could probably be used in other places as well.
> Strawman example:
> >
> >   // Use:
> >   if fu < br %(case: .insensitive, locale: .current) { … }
> >
> >   // Definition:
> >   func < (lhs: String, rhs: String, case: StringCaseSensitivity? =
> nil, …) -> Bool { … }
> >
> > 6. Punt on this until we have macros. Once we do, have the function be a
> macro which alters the comparisons passed to it. Bad part is that this
> doesn't give us a solution for at least a version or two.
> ___
> 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] A case for postponing ABI stability

2017-01-24 Thread Georgios Moschovitis via swift-evolution 
> I'm not really sure if the String-changes affect the ABI, but none the less, 
> I strongly agree with your opinion that things shouldn't be done in a hurry, 
> and I hope that Swift keeps the courage to break things for the better 
> (sporadically ;-)

+1

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

[swift-evolution] String Comparison (was: Strings in Swift 4)

2017-01-24 Thread Jonathan Hull via swift-evolution 
Breaking this into a different thread…

One suggestion which I haven’t seen (maybe it is too crazy) is the idea of 
introducing shadowing of operators within a scope (similar to variables).

Now this would need a TON of design work to make it actually work, but the gist 
would be:

if blah == foo {
//We can override/shadow the ‘<‘ operator within this scope as 
long as the signature is the same
let (<) = String.comparisonOperation(case: .insensitive, 
locale: .current) //Here we grab a closure produced by a static function on 
String

if a < b {  //Within this scope < will be case insensitive
//Stuff
}
}
//Outside of the scope, < is back to it’s lovable self


Thoughts on the general idea?

Thanks,
Jon


> I know you want to defer this for now, so feel free to set this part of the 
> email aside, but here's a quick list of solutions I've ballparked:
> 
> 1. Your "one operand carries the options" solution.
> 
> 2. As I mentioned, do something that effectively overloads comparison 
> operators to return them in a symbolic form. You're right about the ambiguity 
> problem, though.
> 
> 3. Like #2, but with slightly modified operators, e.g.:
> 
>   if localized(fu &< br, case: .insensitive) { … }
> 
> 4. Reintroduce something like the old `BooleanType` and have *all* 
> comparisons construct a symbolic form that can be coerced to boolean. This is 
> crazy, but actually probably useful in other places; I once experimented with 
> constructing NSPredicates like this.
> 
>   protocol BooleanProtocol { var boolValue: Bool { get } }
>   
>   struct Comparison {
>   var negated: Bool
>   var sortOrder: SortOrder
>   var left: Operand
>   var right: Operand
>   
>   func evaluate(_ actualSortOrder: SortOrder) -> Bool {
>   // There's circularity problems here, because `==` 
> would itself return a `Comparison`, 
>   // but I think you get the idea.
>   return (actualSortOrder == sortOrder) != negated
>   }
>   }
>   extension Comparison: BooleanProtocol {
>   var boolValue: Bool {
>   return evaluate(left.compared(to: right))
>   }
>   }
>   
>   func < (lhs: ComparableType, rhs: 
> ComparableType) -> Comparison {
>   return Comparison(negated: false, sortOrder: .before, left: 
> lhs, right: rhs)
>   }
>   func <= (lhs: ComparableType, rhs: 
> ComparableType) -> Comparison {
>   return Comparison(negated: true, sortOrder: .after, left: lhs, 
> right: rhs)
>   }
>   // etc.
>   
>   // Now for our special String comparison thing:
>   func localized(_ expr: Comparison, case: StringCaseSensitivity? 
> = nil, …) -> Bool {
>   return expr.evaluate(expr.left.compare(expr.right, case: case, 
> …))
>   }
> 
> 5. Actually add some all-new piece of syntax that allows you to add options 
> to an operator. Bad part is that this is ugly and kind of weird; good part is 
> that this could probably be used in other places as well. Strawman example:
> 
>   // Use:
>   if fu < br %(case: .insensitive, locale: .current) { … }
>   
>   // Definition:
>   func < (lhs: String, rhs: String, case: StringCaseSensitivity? = nil, 
> …) -> Bool { … }
> 
> 6. Punt on this until we have macros. Once we do, have the function be a 
> macro which alters the comparisons passed to it. Bad part is that this 
> doesn't give us a solution for at least a version or two.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A case for postponing ABI stability

2017-01-24 Thread Jonathan Hull via swift-evolution 
I definitely agree.

With Swift 3, especially near the end, we had a bunch of changes that were 
rushed in because “we won’t have a chance to change it later, so let’s do it 
just in case”.  I think setting these deadlines leads to worse choices overall.

That said, we do need stability so that we can start to build things that we 
know will last.  I have ObjC programs which are years old and still work fine, 
but I have to update my Swift projects every 6 months to get them to compile.

What I would like to see instead of these deadlines for the whole language is 
for parts of the language to be stabilized over time.  That is each part of the 
language and standard library would be marked one of the following:

• Unstable - This is in active development or is expected to have major changes 
soon. You can build things with it, but expect to have to update that code.
• Pre-stable - We have a design that we think works, and only expect minor 
tweaks, but we need to see how it works in the wild for a while before we know 
it is correct.
• Stable - This is a proven design that we feel comfortable baking in to the 
language. It has been tested in real world code and we are confident it won’t 
need to change in ways that break backward/forward compatibility.

Then each API would have this listed in the documentation.  I think that the 
most we should start things at right now is “Pre-stable” given the pending 
updates from generics, concurrency, etc… that will affect wide swaths of the 
language.

For example, the new Arithmetic stuff would be Pre-stable because we think it 
will be our design, but we may have small tweaks once we see how it interacts 
with other API in the real world.  Then if it works as well as we think it 
will, we can move it to Stable in the following release.  String would be 
unstable right now due to the planned upgrades.

Breaking things up like this allows us to focus and take time on each part… 
baking things in as we are confident that they are the right choice.  It also 
allows the developer community to plan accordingly and predict which parts of 
their code will need to be updated.  I kind of feel like we are lying to 
ourselves with the current system.

Thanks,
Jon


> On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello swift-evolution,
> 
> ABI stability is an important feature which many Swift users are looking 
> forward to. If I understand it correctly, once it’s here, the Standard 
> Library becomes part of that ABI and only additive and backwards-compatible 
> changes can be done. Seeing how we are still heavily modifying the Standard 
> Library this year (Strings), wouldn’t it be wiser to let those changes simmer 
> under the scrutiny of the broader community of Swift users for a year before 
> we make it into the ABI?
> 
> ABI compatibility is important. Some projects need it, but I think that most 
> projects (most Apple platform third-party applications) would only mildly 
> benefit from it. But I want to make sure the Standard Library has had enough 
> time to mature before we set it in stone.
> 
> Regards,
> David.
> ___
> 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] Strings in Swift 4

2017-01-24 Thread Goffredo Marocchi via swift-evolution 
That is quite tricky without breaking the ties Swift and Foundation/Standard 
Library have with Apple platforms or making the language needing better and 
better language lawyers to fully understand its specs.

Sent from my iPhone

> On 24 Jan 2017, at 09:35, Russ Bishop via swift-evolution 
>  wrote:
> 
> 
>> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> ### Formatting
>> 
>> A full treatment of formatting is out of scope of this proposal, but
>> we believe it's crucial for completing the text processing picture.  This
>> section details some of the existing issues and thinking that may guide 
>> future
>> development.
>> 
> 
> Filesystem paths are Strings on Apple platforms but not on Linux. How are we 
> going to square that circle? What about Swift on the server, where 
> distinguishing HTML and JavaScript is security-critical? There are huge 
> security implications to string processing, often around platforms making it 
> easy to do the wrong thing in a careless way and promoting ad-hoc formatting, 
> serialization and parsing. That’s a huge area to consider of course but it 
> might be worth thinking about how a ergonomic API for a few example cases 
> would work. 
> 
> I guess my point is that formatting and interpolation is far more than “just 
> formatting”; making the right thing difficult will directly lead to 
> exploitable security vulnerabilities or not as the case may be. (To be clear 
> I’m not saying the follow-on proposals from this need to solve those 
> problems, maybe just give them some consideration).
> 
> 
> 
>> ## Open Questions
>> 
>> ### Must `String` be limited to storing UTF-16 subset encodings?
>> 
>> - The ability to handle `UTF-8`-encoded strings (models of `Unicode`) is not 
>> in
>> question here; this is about what encodings must be storable, without
>> transcoding, in the common currency type called “`String`”.
>> - ASCII, Latin-1, UCS-2, and UTF-16 are UTF-16 subsets.  UTF-8 is not.
> 
> Depending on who you believe UTF-8 is the encoding of ~65-88% of all text 
> content transmitted over the web. JSON and XML represent the lion’s share of 
> REST and non-REST APIs in use and both are almost exclusively transmitted as 
> UTF-8. As you point out with extendedASCII, a lot of markup and structure is 
> ASCII even if the content is not so UTF-8 represents a significant size 
> savings even on Chinese/Japanese web pages that require 3 bytes to represent 
> many characters (the savings on markup overwhelming the loss on textual 
> content).
> 
> Any model that makes using UTF-8 backed Strings difficult or cumbersome to 
> use can have a negative performance and memory impact. I don’t have a good 
> idea of the actual cost but it might be worth doing some test to determine 
> that.
> 
> Is NSString interop the only reason to not just use UTF-8 as the default 
> storage? If so, is that a solvable problem? Could one choose by typealias or 
> a compiler flag which default storage they wanted?
> 
> 
>> - If we have a way to get at a `String`'s code units, we need a concrete 
>> type in
>> which to express them in the API of `String`, which is a concrete type
>> - If String needs to be able to represent UTF-32, presumably the code units 
>> need
>> to be `UInt32`.
>> - Not supporting UTF-32-encoded text seems like one reasonable design choice.
>> - Maybe we can allow UTF-8 storage in `String` and expose its code units as
>> `UInt16`, just as we would for Latin-1.
>> - Supporting only UTF-16-subset encodings would imply that `String` indices 
>> can
>> be serialized without recording the `String`'s underlying encoding.
> 
> I suppose you could be clever on 64-bit platforms by stealing some bits to 
> indicate the encoding… not that I recommend that :D
> 
>> 
>> ### Do we need a type-erasable base protocol for UnicodeEncoding?
>> 
>> UnicodeEncoding has an associated type, but it may be important to be able to
>> traffic in completely dynamic encoding values, e.g. for “tell me the most
>> efficient encoding for this string.”
> 
> Generalized Existentials 
> tis but happiness by another name
> For we who live 
> in The Land of Protocols and Faeries
> 
>> 
>> ### Should there be a string “facade?”
>> 
>> One possible design alternative makes `Unicode` a vehicle for expressing
>> the storage and encoding of code units, but does not attempt to give it an 
>> API
>> appropriate for `String`.  Instead, string APIs would be provided by a 
>> generic
>> wrapper around an instance of `Unicode`:
>> 
>> ```swift
>> struct StringFacade : BidirectionalCollection {
>> 
>> // ...APIs for high-level string processing here...
>> 
>> var unicode: U // access to lower-level unicode details
>> }
>> 
>> typealias String = StringFacade
>> typealias Substring = StringFacade
>> ```
>> 
>> This design would allow us to de-emphasize lower-level `String` APIs such as
>> access to the specific encoding, by putting them behind

Re: [swift-evolution] Proposal: Remove the "fallthrough" keyword

2017-01-24 Thread John McCall via swift-evolution 
> On Jan 23, 2017, at 9:14 PM, Erica Sadun via swift-evolution 
>  wrote:
> This was previously pitched.
> 
> https://lists.swift.org/pipermail/swift-evolution/2015-December/000231.html 
> 
> 
> Here was the use-case that led to the thread being abandoned: 
> 
> https://gist.github.com/stevestreza/2557dc5ec9e7c694d7ea 
> 
Additionally, it's hard to imagine us removing an innocuous language feature 
after promising source compatibility.  fallthrough is part of Swift now.

If there's a more general language feature that subsumes fallthrough, great, 
but it doesn't actually get to *eliminate* fallthrough.

John.


> 
> -- E
> 
> 
>> On Jan 22, 2017, at 11:23 PM, Russ Bishop via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jan 22, 2017, at 4:53 PM, Dave Abrahams via swift-evolution 
>>> > wrote:
>>> 
>>> Sent from my iPad
>>> 
>>> On Jan 22, 2017, at 3:15 PM, Chris Lattner >> > wrote:
>>> 
 
> On Jan 20, 2017, at 12:22 PM, Dave Abrahams via swift-evolution 
> > wrote:
> 
>> 
>> Yeah, maybe there's a more general language feature that could replace 
>> 'fallthrough' here. Instead
>> of labelling cases, we could support a 'reswitch' statement that 
>> redispatches the switch to the case
>> matching the operand:
>> 
>>switch some_value {
>>case .REFINED:
>>if !validate(some_value) { return NULL }
>>reswitch .BASE
>> 
>>case .BASE:
>>handle_enum_value();
>>}
> 
> We should just call a spade a spade and spell that "goto" ;-)
 
 Goto has traditionally been used for unstructured control flow, but this 
 form is still fully structured.  You cannot produce irreducible loops, 
 jump into scopes, over declarations, etc.
>>> 
>>> It would be useful to know the technical definition of "structured." The 
>>> fact is that there's a large category of sensible goto-like jumps that we 
>>> probably want to allow and I see no advantage to giving them all distinct 
>>> names.  I don't believe users will distinguish them.  We already have 
>>> "break looplabel" and, aside from the label being in the wrong place, it's 
>>> effectively a goto.  It seems to me we should just have goto and either 
>>> prohibit the troublesome uses or give them reasonable semantics.
>>> 
>>> I could live with "break" as well as "goto", but it feels a bit like it's 
>>> pretending to be something it isn't, and there's the source compatibility 
>>> problem with the label position.
>>> 
>>> -Dave
>> 
>> I always assumed structured control flow means control only jumps to 
>> approved points, not arbitrary statements. Implicitly this is jumping out of 
>> a scope to a less-nested scope but never into a more-nested scope.
>> 
>> Swift takes this even further: you are limited to early exit of control 
>> flow. That’s a lot more restrictive than arbitrary goto.
>> 
>> 
>> Russ
>> 
>> ___
>> 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] Strings in Swift 4

2017-01-24 Thread Russ Bishop via swift-evolution 

> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution 
>  wrote:
> 
> ### Formatting
> 
> A full treatment of formatting is out of scope of this proposal, but
> we believe it's crucial for completing the text processing picture.  This
> section details some of the existing issues and thinking that may guide future
> development.
> 

Filesystem paths are Strings on Apple platforms but not on Linux. How are we 
going to square that circle? What about Swift on the server, where 
distinguishing HTML and JavaScript is security-critical? There are huge 
security implications to string processing, often around platforms making it 
easy to do the wrong thing in a careless way and promoting ad-hoc formatting, 
serialization and parsing. That’s a huge area to consider of course but it 
might be worth thinking about how a ergonomic API for a few example cases would 
work. 

I guess my point is that formatting and interpolation is far more than “just 
formatting”; making the right thing difficult will directly lead to exploitable 
security vulnerabilities or not as the case may be. (To be clear I’m not saying 
the follow-on proposals from this need to solve those problems, maybe just give 
them some consideration).



> ## Open Questions
> 
> ### Must `String` be limited to storing UTF-16 subset encodings?
> 
> - The ability to handle `UTF-8`-encoded strings (models of `Unicode`) is not 
> in
>  question here; this is about what encodings must be storable, without
>  transcoding, in the common currency type called “`String`”.
> - ASCII, Latin-1, UCS-2, and UTF-16 are UTF-16 subsets.  UTF-8 is not.

Depending on who you believe UTF-8 is the encoding of ~65-88% of all text 
content transmitted over the web. JSON and XML represent the lion’s share of 
REST and non-REST APIs in use and both are almost exclusively transmitted as 
UTF-8. As you point out with extendedASCII, a lot of markup and structure is 
ASCII even if the content is not so UTF-8 represents a significant size savings 
even on Chinese/Japanese web pages that require 3 bytes to represent many 
characters (the savings on markup overwhelming the loss on textual content).

Any model that makes using UTF-8 backed Strings difficult or cumbersome to use 
can have a negative performance and memory impact. I don’t have a good idea of 
the actual cost but it might be worth doing some test to determine that.

Is NSString interop the only reason to not just use UTF-8 as the default 
storage? If so, is that a solvable problem? Could one choose by typealias or a 
compiler flag which default storage they wanted?


> - If we have a way to get at a `String`'s code units, we need a concrete type 
> in
>  which to express them in the API of `String`, which is a concrete type
> - If String needs to be able to represent UTF-32, presumably the code units 
> need
>  to be `UInt32`.
> - Not supporting UTF-32-encoded text seems like one reasonable design choice.
> - Maybe we can allow UTF-8 storage in `String` and expose its code units as
>  `UInt16`, just as we would for Latin-1.
> - Supporting only UTF-16-subset encodings would imply that `String` indices 
> can
>  be serialized without recording the `String`'s underlying encoding.

I suppose you could be clever on 64-bit platforms by stealing some bits to 
indicate the encoding… not that I recommend that :D

> 
> ### Do we need a type-erasable base protocol for UnicodeEncoding?
> 
> UnicodeEncoding has an associated type, but it may be important to be able to
> traffic in completely dynamic encoding values, e.g. for “tell me the most
> efficient encoding for this string.”

Generalized Existentials 
tis but happiness by another name
For we who live 
in The Land of Protocols and Faeries

> 
> ### Should there be a string “facade?”
> 
> One possible design alternative makes `Unicode` a vehicle for expressing
> the storage and encoding of code units, but does not attempt to give it an API
> appropriate for `String`.  Instead, string APIs would be provided by a generic
> wrapper around an instance of `Unicode`:
> 
> ```swift
> struct StringFacade : BidirectionalCollection {
> 
>  // ...APIs for high-level string processing here...
> 
>  var unicode: U // access to lower-level unicode details
> }
> 
> typealias String = StringFacade
> typealias Substring = StringFacade
> ```
> 
> This design would allow us to de-emphasize lower-level `String` APIs such as
> access to the specific encoding, by putting them behind a `.unicode` property.
> A similar effect in a facade-less design would require a new top-level
> `StringProtocol` playing the role of the facade with an an `associatedtype
> Storage : Unicode`.
> 
> An interesting variation on this design is possible if defaulted generic
> parameters are introduced to the language:
> 
> ```swift
> struct String 
>  : BidirectionalCollection {
> 
>  // ...APIs for high-level string processing here...
> 
>  var unicode: U // access to lower-level unicode

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Gwendal Roué via swift-evolution 
Now that I think more about it, tainting strings with a comparison behavior may 
be a bad idea:

// not a so good idea, after all
let foo = "foo".comparison(case: .insensitive, locale: .current)

Problems are:

- Two strings tainted with the same comparison behavior should be comparable, 
but two strings tainted with different behaviors should not. I'm not sure that 
the Swift type system allows that. In the current state of affairs, such 
restrictions are only available to *types*, which implies that comparisons 
should be types as well. But types can't be built at runtime from other types: 
there's not way for a runtime-chosen locale to be able to build a type.

- Tainting strings is an old, and unsolved problem. If you're allowed to taint 
for comparison, why can't you taint for confidence (user input), needing 
escaping (for HTML, shell, SQL, javscript, etc.), and a whole bunch of other 
dimensions I don't even think of? We're already discussing different types for 
strings and substrings... Do we really want a combinatorial explosion of types?

- Should we restrict support for comparison behaviors to strings only? 
`Sequence.lexicographicallyPrecedes(_:by:)` is interested in comparison 
behaviors as well, and it extends much further than just Strings.

So all in all, I think that isolating comparison behaviors from Strings may be 
a much better idea.

Gwendal

> Le 24 janv. 2017 à 08:18, David Hart  a écrit :
> 
> Seems like a good solution to me.
> 
> On 24 Jan 2017, at 05:29, Gwendal Roué via swift-evolution 
> > wrote:
> 
>> 
>>> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution 
>>> > a écrit :
>>> 
> The operands and sense of the comparison are kind of lost in all this 
> garbage. You really want to see `foo < bar` in this code somewhere, but 
> you don't.
 
 Yeah, we thought about trying to build a DSL for that, but failed.  I 
 think the best possible option would be something like:
 
  foo.comparison(case: .insensitive, locale: .current) < bar
 
 The biggest problem is that you can build things like
 
fu = foo.comparison(case: .insensitive, locale: .current)
br = bar.comparison(case: .sensitive)
fu < br // what does this mean?
 
 We could even prevent such nonsense from compiling, but the cost in 
 library API surface area is quite large.
>>> 
>>> Is it? I think we're talking, for each category of operation that can be 
>>> localized like this:
>>> 
>>> * One type to carry an operand and its options.
>>> * One method to construct this type.
>>> * One alternate version of each operator which accepts an operand+options 
>>> parameter. (I'm thinking it should always be the right-hand side, so the 
>>> long stuff ends up at the end; Larry Wall noted this follows an "end-weight 
>>> principle" in natural languages.)
>>> 
>>> I suspect that most solutions will at least require some sort of overload 
>>> on the comparison operators, so this may be as parsimonious as we can get. 
>> 
>> SQL has the `collate` keyword:
>> 
>>  -- sort users by email, case insensitive
>>  select * from users order by email collate nocase
>>  -- look for a specific email, in a case insensitive way
>>  select * from users where email = 'f...@example.com 
>> ' collate nocase
>> 
>> It is used as a decorator that modifies an existing sql snippet (a sort 
>> descriptor first, and a comparison last)
>> 
>> When designing an SQL building to Swift, I chose the 
>> `nameColumn.collating(.nocase)` approach, because it allowed a common Swift 
>> syntax for both use cases:
>> 
>>  // sort users by email, case insensitive
>>  User.order(nameColumn.collating(.nocase))
>>  // look for a specific email, in a case insensitive way
>>  User.filter(nameColumn.collating(.nocase) == "f...@example.com 
>> ")
>> 
>> Yes, it comes with extra operators so that nonsensical comparison are 
>> avoided.
>> 
>> But it just works.
>> 
>> Gwendal
>> 
>> ___
>> 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] Reduce with inout

2017-01-24 Thread Florent Bruneau via swift-evolution 
Hi,

Looks like there is a typo in the proposal:

func reduce(mutating: A, _ combine: (inout A, Iterator.Element) -> ()) 
-> A {
var result = initial

This makes use of `initial` that is not defined, should be:

func reduce(mutating initial: A, _ combine: (inout A, Iterator.Element) 
-> ()) -> A {
var result = initial

> Le 24 janv. 2017 à 08:54, Chris Eidhof via swift-evolution 
>  a écrit :
> 
> I've thought about it for a few days, and really like `reduce(mutating:_)`. 
> I've updated the PR, and am now happy for this to go into review.
> 
> https://github.com/apple/swift-evolution/pull/587
> 
> On Mon, Jan 23, 2017 at 8:27 AM, Russ Bishop  wrote:
> 
>> On Jan 22, 2017, at 10:56 PM, Chris Eidhof  wrote:
>> 
>> Not as a direct reply to Russ, but just to reiterate: to me, there are two 
>> clear benefits of using the `inout` version of reduce:
>> 
>> 1. The performance (currently discussed at length)
>> 2. Readability (because we can use mutating methods on `inout` arguments).
>> 
>> Even if the compiler were to optimize the unnecessary copy of `return arr + 
>> [el]` away, there are still a lot of other mutable methods that you might 
>> want to use within the reduce closure. So I think the proposal is still very 
>> valid even if the compiler optimizations would magically appear tomorrow.
>> 
>> To push this proposal forward a little bit, I'd like to come up with a good 
>> name. It seems like we shouldn't overload `reduce`, but choose a different 
>> name, so that we don't stress the typechecker. Any other suggestions?
>> 
>> On Mon, Jan 23, 2017 at 7:11 AM, Russ Bishop  wrote:
>> -- 
>> Chris Eidhof
> 
> 
> Sorry for the derail!
> 
> reduce(mutating:_:) { } is still my favorite; You can take mutating to mean 
> we will copy the value now but mutate it later.
> 
> 
> Some alternatives:
> 
> reduce(forMutating:_:) { }
> 
> reduce(forInout:_:) { }
> 
> reduce(initial:_:) { }
> 
> reduce(copying:mutate:) { }
> 
> // just kidding...
> reduce(copyForLaterMutating:_:) { }
> 
> 
> 
> It should definitely be some form of reduce. 
> 
> Russ
> 
> 
> 
> -- 
> Chris Eidhof
> ___
> 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] A case for postponing ABI stability

2017-01-24 Thread Tino Heth via swift-evolution 
Imho the major problem is that there's quite a lot confusion about what ABI 
stability actually means — and a lot uncertainty which proposals would actually 
affect it.
People with more insight may prove me wrong, but I'll lay out my understanding 
in the next paragraph:
It shouldn't be hard to have several versions of the stdlib installed, and no 
one talks about API stability (which is great as well — but a superior API imho 
is better ;-)
ABI is very low level and affects the junction of software and hardware (which 
bits are put into which location when a function call happens, utilisation of 
registers…).

I'm not really sure if the String-changes affect the ABI, but none the less, I 
strongly agree with your opinion that things shouldn't be done in a hurry, and 
I hope that Swift keeps the courage to break things for the better 
(sporadically ;-)

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

Re: [swift-evolution] Strings in Swift 4

2017-01-24 Thread Chris Eidhof via swift-evolution 
I agree that being able to implement parsers in a nice way can be a huge
step forward in being really good at string processing.

There are a couple of possibilities that come to mind directly:

1. Build parsers right into the language (like Perl 6 grammars)
2. Provide a parser combinator language (e.g.
https://github.com/davedufresne/SwiftParsec).
3. Rely on external tools like bison/yacc/etc.
4. Make it easy for people to write hand-written parsers (e.g. by providing
an NSScanner alternative).

Some obvious drawbacks of each approach:

1. Lots of work, probably hard to get right?
2. Only way to do this, afaik, is using lots of functional programming
which might scare people off. Also probably it's hard to get performance as
fast as 1.
3. No clear integrated way to do this
4. You still have to know how to write a parser.

I would think that 4. would be a good step forward, and 1/2 would
definitely benefit from this.

Also, I'd love to have this functionality on sequence/collection types,
rather than Strings. For example, it can be tremendously helpful to parse a
binary format using proper parsers. Or maybe you would want to use an
event-driven XML parser as "tokenizer" and parse that. Plenty of cool
possibilities.

On Tue, Jan 24, 2017 at 8:46 AM, Russ Bishop via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jan 23, 2017, at 2:27 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado 
> wrote:
>
> Taken from NSHipster :
>
>> Happily, on one thing we can all agree. In NSRegularExpression, Cocoa has
>> the most long-winded and byzantine regular expression interface you’re ever
>> likely to come across.
>
>
> There is no way to achieve the goal of being better at string processing
> than Perl without regular expressions being addressed. It just should not
> be ignored.
>
>
>
> We’re certainly not ignoring the importance of regexes. But if there’s a
> key takeaway from your experiences with NSRegularExpression, it’s that a
> good regex implementation matters, a lot. That’s why we don’t want to rush
> one in alongside the rest of the overhaul of String. Instead, we should
> take our time to make it really great, and building on a solid foundation
> of a good String API that’s already in place should help ensure that.
>
>
> I do think that there's some danger to focusing too narrowly on regular
> expressions as they appear in languages today. I think the industry has
> largely moved on to fully-structured formats that require proper parsing
> beyond what traditional regexes can handle. The decades of experience with
> Perl shows that making regexes too easy to use without an easy ramp up to
> more sophisticated string processing leads to people cutting corners trying
> to make regex-based designs kind-of work. The Perl 6 folks recognized this
> and developed their "regular expression" support into something that
> supported arbitrary grammars; I think we'd do well to start at that level
> by looking at what they've done.
>
> -Joe
>
>
> I fully agree. I think we could learn something from Perl 6 grammars. As
> PCREs are to languages without regex, Perl 6 grammars are to languages with
> PCREs.
>
> A lot of really crappy user interfaces and bad tools come down to
> half-assed parsers; maybe we can do better? (Another argument against
> rushing it).
>
>
> Russ
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


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