Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

[Martin Waitz via swift-evolution]

Hello Brent,

> Am 10.01.2018 um 06:15 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> For what it's worth, I *might* introduce a follow-up proposal with 
> conformances for Bool and Optional. Their straightforwardness and utility 
> make them very tempting.

A conditional conformance for Optional could in fact be useful, but what’s the 
use-case for Bool?
If somebody needs a Bool conformance for generic code, it’s extremely simple to 
just define conformance herself.
If we see that people really do need Bool conformance, we can still add it at 
any time.

> (The only questions are whether `false` and `nil` should be first or last. 
> But if the default isn't right for your use case, you can always make your 
> own static property instead of using the standard library's.)

I would start with the default initialiser.

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hi,

> With a protocol defining random() and random(in:), you could write generic 
> algorithms on things which know how to create themselves from a RNG.  With 
> your approach the RNG has to provide a way to get a random value for each 
> type you want to support.

This is right, if we want a generic prototype for construction of random 
objects, well then we need such a protocol and a new method or initializer.
However, I‘m not yet convinced that such a protocol is necessary.
Most objects will be constructed using randomized values, according to the use 
case at hand. A generic randomizable protocol would not help here.

> For example, without random(in:) or random(), how would you get a CGFloat 
> between 0 and 1?  Ranges are only collections if they are countable…

I was assuming that there would be a random.draw(from:) for ranges.

>> extension RandomFoo {
>>   func draw(from urn: T) -> T.Element? {
>>   guard !urn.isEmpty else { return nil }
>>   let idx = draw(from: urn.indices)
>>   return urn[idx]
>>   }
>> }
>> 
> This will call itself repeatedly and hang...

You are right, Collection.indices is also a Collection. We have to explicitly 
use the range here.

>> We just have to define one base protocol for such extensions. Every random 
>> number generator then automatically knows how to draw elements from ranges 
>> and collections.
> 
> It isn’t automatic, thought.  How would I get a random color?

This has already been discussed: you either want some random color from a fixed 
set, or you want to produce a new color using some random values. A completely 
random color it totally useless.

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hello,

> The collection is a subject which has elements, and we are asking for one of 
> them at random.

it has elements, sure.
And because of its structure, it has a first and a last element and whatever.
But that random element is not an inherent property of the collection.

I find it much more natural to use the random number generator to draw random 
elements from collections than the other way round.
That approach also completely side-steps the problem with having to define 
default arguments. The user can just use any random number generator she has. 
Obviously, it makes sense to provide a default one named `random` to make it 
easily accessible.

>>> var list = [1,2,3,4]
>>> let a:Int? = list.randomElement //List is still [1,2,3,4] and ‘a’ contains 
>>> one of the elements
>> 
>> Instead I would prefer to have something like:
>> 
>> let a = random.draw(from: list)
> 
> But now the RNG has to understand the concept of collections. I would argue 
> it is much cleaner to write an extension on Collection.
> 
> func randomElement(using source: RandomSource = .default) -> Element? {
>   guard !isEmpty else {return nil}
>   let idx = Int.random(in: 0…(count - 1), using: source)
>   return self[idx]
> }

But then the Collection has to understand the concept of random numbers. ;-)
Well both approaches are equally clean from this point of view:

extension RandomFoo {
func draw(from urn: T) -> T.Element? {
guard !urn.isEmpty else { return nil }
let idx = draw(from: urn.indices)
return urn[idx]
}
}

We just have to define one base protocol for such extensions. Every random 
number generator then automatically knows how to draw elements from ranges and 
collections.

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hi,

>>> This is redundant. In order to pick a random element, you’re saying I 
>>> should have to do “Int.random(0 ..< 10)”? The redundancy here is that I 
>>> have to specify Int twice: once for the “.random” call, and again for the 
>>> type of the range. We can do better than that.
> 
> I don’t see how this is redundant—do you mean that you’d need to write out 
> the type name instead of writing `(0..<10).random()!`? I continue to be of 
> the opinion that picking a random integer/floating-point value/Boolean and 
> picking a random element from a collection are two different operations.

Well, I don‘t see a big difference beteeen ranges and collections here. We can 
support both with the same syntax:

let a = random.draw(from: 1...3)
let b = random.draw(from: [1, 2, 3])

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hello Jonathan,

> For collections, I think we should call returning a random element 
> -randomElement, and choosing a random element without replacement 
> -popRandomElement

I disagree because I don’t think that the random data is a property of the 
collection.
The collection is not the subject which has random elements, it’s more the 
object which is used when drawing an element.

> var list = [1,2,3,4]
> let a:Int? = list.randomElement //List is still [1,2,3,4] and ‘a’ contains 
> one of the elements

Instead I would prefer to have something like:

let a = random.draw(from: list)

> let b:Int? = list.popRandomElement //Now list contains all the elements 
> except the one in ‚b’

we already have remove(at:), this can be used trivially:

let b = list.remove(at: random.draw(from: list.indices))

a little bit more verbose, but easily understandable.
It uses well known building blocks and does not increase the API surface of 
collections.

— Martin

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hi Erica,

> Doesn't `choose` usually take two arguments, the `count` to choose 
> (presumably defaulting to 1) and the collection to choose `from`?

This might be useful for collections, when you want to draw several elements 
without drawing the same element twice.
For ranges of random numbers you usually need independent numbers and just call 
the generator multiple times.
Both use cases could be provided as overloads (a default argument would require 
that the return value has the same type, which would be unfortunate here).

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

Re: [swift-evolution] [Proposal] Random Unification

[Martin Waitz via swift-evolution]

Hello,

> Maybe we call the default RNG instance `random`, and then give the 
> `random(in:)` methods another name, like `choose(in:)`?
> 
>   let diceRoll = random.choose(in: 1...6)
>   let card = random.choose(in: deck)
>   let isHeads = random.choose(in: [true, false])
>   let probability = random.choose(in: 0.0...1.0)
>   
>   let diceRoll = rng.choose(in: 1...6)
>   let card = rng.choose(in: deck)
>   let isHeads = rng.choose(in: [true, false])
>   let probability = rng.choose(in: 0.0...1.0)

I like this design a lot. After all, `random` is not a property of some type or 
instance, but we want to generate a new random element within some range/based 
on some given set.
Modeling that as methods of the RNG seems to be much more natural.

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

Re: [swift-evolution] [Concurrency] Async/Await

[Martin Waitz via swift-evolution]

Hello,

> Am 22.08.2017 um 18:32 schrieb Joe Groff via swift-evolution 
> :
> The feature provides general delimited continuations. You could write an 
> IteratorProtocol-conforming interface over a coroutine like this:
> 
>  private func yield(_ value: T) async -> Void {
>self.next = value
>await suspendAsync { cont in
>  resume = cont
>}
>  }
> 
> 
> This isn't ideal in a number of ways (awkward, not particularly efficient, 
> and has the gotcha that the generator's `body` could suspend itself with 
> something other than the `yield` operation, doesn't integrate with ownership 
> in the way John proposes in the ownership manifesto), so it may not be a good 
> idea, of course.


I still have trouble understanding how exactly suspendAsync is going to work.
Is the body called right away or is it put into some dispatch queue on another 
thread?
Does the continuation function return immediately (besides queueing 
suspendAsync to also return)?

How does this correlate with coroutines?
There is no extra stack for the coroutine (which runs the generator function), 
right?
In my mental model, the generator function is split into individual functions 
which are queued one after another, but reusing the same thread/stack, is this 
correct?

How would a generator feature without the mentioned shortcomings look like?

Thanks for any help in understanding how it works!
And thanks for all the great work, this looks like a nice basis for future 
Swift :-)

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

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Martin Waitz via swift-evolution]

Hi Haravikk,

Am 2017-08-10 11:07, schrieb Haravikk via swift-evolution:

I don't feel that conforming to
Equatable/Hashable is sufficient as an opt-in. Consider for example
someone who declares their type as Equatable/Hashable, then sets to
work on the details of their type, forgetting to implement the actual
equatable/hashable behaviour they want.


This is no different than a default implementation of the protocol.
In fact, the proposal just adds something like this:

extension Struct: Equatable where A: Equatable, B: 
Equatable, ... {
static func ==(lhs: Self, rhs: Self) -> Bool { /* insert 
implementation here */ }

}

We don't require/support some special keywords for other protocols with 
default implementation either,

so I see no reason to add them here.

Your concerns are orthogonal to this proposal and should be discussed 
independently.


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

Re: [swift-evolution] [Pitch] Object aliases

[Martin Waitz via swift-evolution]

Hi again,


> Hello,
> 
>> Am 30.06.2017 um 10:55 schrieb Daryle Walker via swift-evolution 
>> >:
>> 
>> I was thinking posing aliases would be like symbolic substitution; we could 
>> replace the alias with the text defining its source expression everywhere 
>> and there should be no efficiency change. But I would want any evaluation of 
>> the (sub-)object’s location to be computed once; is that where complexity 
>> could come in? I was hoping that object location determination could be done 
>> at compile-time; that’s the reason for restricting what kinds of objects can 
>> be a source object.
> 
> Have you had a look at local `inout` bindings as proposed in the Ownership 
> Manifesto[1]?

yes of course you have, because you already replied to John ;-)
sorry for not reading the complete thread :-/

And yes, these local bindings would effectively just be a new binding for the 
same memory location.
This way it really would be a compile-time alias.

— Martin


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

Re: [swift-evolution] [Pitch] Object aliases

[Martin Waitz via swift-evolution]

Hello,

> Am 30.06.2017 um 10:55 schrieb Daryle Walker via swift-evolution 
> :
> 
> I was thinking posing aliases would be like symbolic substitution; we could 
> replace the alias with the text defining its source expression everywhere and 
> there should be no efficiency change. But I would want any evaluation of the 
> (sub-)object’s location to be computed once; is that where complexity could 
> come in? I was hoping that object location determination could be done at 
> compile-time; that’s the reason for restricting what kinds of objects can be 
> a source object.

Have you had a look at local `inout` bindings as proposed in the Ownership 
Manifesto[1]?
Do they solve your problem?

— Martin

[1]: 
https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md#local-ephemeral-bindings
 

 

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

Re: [swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

[Martin Waitz via swift-evolution]

> * What is your evaluation of the proposal?

I’m in favour of this proposal.
It solves the problems I have with the current behaviour of the swift package 
manager.

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

yes.
While the existing auto-pinning feature can be used to get reproducible 
dependency versions,
it has some deficiencies which make it more complicated than required for the 
common cases without really solving the more exotic use cases.
Package pinning vs. requiring a specific revision in Package.swift also felt 
like two overlapping features without a clear motivation for one versus the 
other.

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

yes.
It focuses on doing one thing well without precluding other user use cases.
The new behaviour defaults does the right thing(TM) for the common use cases 
and is easily explained.
Especially now that we are already able to require specific versions within 
Package.swift, SE-0150+SE-0175 provide a nice set of orthogonal features.

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

Never used a package manager with this kind of dependency resolution and always 
wanted to have one.

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

Took part in the discussions for SE-0145 and now read SE-0175.

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

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Martin Waitz via swift-evolution]

Hello,

Many of the listed package managers are for interpreted languages.
So after fetching all dependencies, your package is completely usable. It is 
„installed locally“.
But Swift packages have to be compiled. You have to build them to be able to 
use them.
For me, ‚install' comes after compilation, not before.

Using ‚resolve‘ is thus a much better name for the proposed command.
The verb ‚install‘ should only be used when it really installs the package in 
some way.

— 
Martin
 
> Am 01.05.2017 um 00:46 schrieb Jon Shier via swift-evolution 
> :
> 
>   `install` only sounds like it should install things in the system if 
> that’s the only type of manager you’ve ever used. If I’ve only ever used 
> brew, of course I’ll assume that every other thing that calls itself a 
> package manager will operate similarly. Thankfully, people learn quickly and 
> it’s pretty easy to tell the difference between project package managers and 
> system package mangers. Pretty much anyone developing on Apple platforms will 
> be familiar with brew and CocoaPods  / bundler, all of which use the 
> `install` verb, so following those would be an easy way to gain immediate 
> familiarity. SPM really shouldn't be too different given that it will have to 
> interoperate on systems with these tools, so choosing your own verbs would be 
> far more confusing than using `install`. Carthage’s use of `bootstrap` is 
> weird outlier that is always confusing to me. Plus, using `install`, allows 
> you to use `.installed` for the file, which I think makes more sense than 
> `.lock` or `.resolved`.
>   A second issue is that `resolve` doesn’t sound like it installs 
> anything at all. It sounds like a command that would just print the resolved 
> versions of all my dependencies but do nothing else. 
> 
> 
> 
> Jon
> 
> 
>> On Apr 30, 2017, at 12:06 AM, Rick Ballard via swift-evolution 
>> > wrote:
>> 
>> Thanks for the feedback, David, and apologies for the slow reply. My biggest 
>> reservation with the word "install" is that it really sounds like it should 
>> install things into the system, or another shareable location, instead of 
>> fetching dependencies into the dependency location for a single top-level 
>> package. We might actually want to add a real "install" command that does 
>> some type of installation some day in the future, though we might also 
>> choose to forever leave that sort of thing to your system package manager. 
>> And while there is some precedence for other package managers using 
>> "install" to fetch dependencies, I think there's broader precedence for it 
>> meaning to either install things into the system, or at least create an 
>> installable "build root", with e.g. `make install`, `xcodebuild install`, 
>> `brew install`, etc.
>> 
>> I just did a quick survey of the same package managers I surveyed previously 
>> to see if they all used this term, and here's what I found:
>> 
>> yarn: `install`
>> composer: `install`
>> cargo: No true equivalent, just supprts `update` or `build`. Also, uses 
>> `install` to mean something different – `cargo install` installs binary 
>> packages only, to a installation root.
>> bundler: `install`
>> cocoapods: `install`
>> glide: `install`
>> pub: `get`
>> mix: `deps.get`
>> rebar3: `get-deps`
>> carton: `install`
>> carthage: `bootstrap`
>> pip: Uses `install`, but since pip doesn't enforce the top-level-package 
>> seperation of SwiftPM, Pip's use of `install` is actually more accurate.
>> npm: `install`
>> meteor: no true equivalent, just supports `update` or `build`
>> 
>> Given that this isn't a universal term, I think I'm comfortable going 
>> against the flow a little bit if it means that we get to have clear and 
>> accurate command-line verbs. But I think this is worth adding to the 
>> "Alternatives Considered" section before we put this up for review!
>> 
>>  - Rick

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

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Martin Waitz via swift-evolution]

Hello Rick,

thanks for the great proposal!
Strong +1 from me :-)

— Martin

> Am 27.04.2017 um 02:25 schrieb Rick Ballard via swift-evolution 
> :
> 
> Hi all,
> 
> We have a proposal we'd like feedback on to revise how Swift Package Manager 
> dependency resolution, updating, and pinning works. These changes weren't 
> planned in the roadmap we published a few months ago, but it's become clear 
> since then that we have some holes in our dependency resolution behavior that 
> need fixing. We've also come to the conclusion that our original design for 
> pinning was overcomplicated and should be revised.
> 
> Please give us your feedback; we're hoping to submit this proposal for 
> official review next week.
> 
> The current draft of the proposal can be found at 
> https://github.com/rballard/swift-evolution/commit/e5e7ce76f29c855aa7162ed3733b09e701d662d6
>  
> .
>  I'm also including it below.
> 
> Thanks,
> 
>   - Rick
> 
> Package Manager Revised Dependency Resolution
> 
> Proposal: SE- 
> 
> Author: Rick Ballard 
> Review Manager: TBD
> Status: Draft in progress
> Bug: TBD
>  
> Introduction
> 
> This proposal makes the package manager's dependency resolution behavior 
> clearer and more intuitive. It removes the pinning commands (swift package 
> pin & swift package unpin), replaces the swift package fetch command with a 
> new swift package resolve command with improved behavior, and replaces the 
> optional Package.pins file with a Package.resolved file which is always 
> created during dependency resolution.
> 
>  
> Motivation
> 
> When SE-0145 Package Manager Version Pinning 
> 
>  was proposed, it was observed that the proposal was overly complex. In 
> particular, it introduced a configuration option allowing some packages to 
> have autopinning on (the default), while others turned it off; this option 
> affected the behavior of other commands (like swift package update, which has 
> a --repinflag that does nothing for packages that use autopinning). This 
> configuration option has proved to be unnecessarily confusing.
> 
> In the existing design, when autopinning is on (which is true by default) the 
> swift package pin command can't be used to pin packages at specific revisions 
> while allowing other packages to be updated. In particular, if you edit your 
> package's version requirements in the Package.swift manifest, there is no way 
> to resolve your package graph to conform to those new requirements without 
> automatically repinning all packages to the latest allowable versions. Thus, 
> specific, intentional pins can not be preserved without turning off 
> autopinning.
> 
> The problems here stem from trying to use one mechanism (pinning) to solve 
> two different use cases: wanting to record and share resolved dependency 
> versions, vs wanting to keep a badly-behaved package at a specific version. 
> We think the package manager could be simplified by splitting these two use 
> cases out into different mechanisms ("resolved versions" vs "pinning"), 
> instead of using an "autopinning" option which makes these two features 
> mutually-exclusive and confusing.
> 
> Additionally, some dependency resolution behaviors were not well-specified 
> and do not behave well. The package manager is lax about detecting changes to 
> the versions specified in the Package.swift manifest or Package.pinspinfile, 
> and fails to automatically update packages when needed, or to issue errors if 
> the version requirements are unsatisfiable, until the user explicitly runs 
> swift package update, or until a new user without an existing checkout 
> attempts to build. We'd like to clarify and revise the rules around when and 
> how the package manager performs dependency resolution.
> 
>  
> Proposed
>  solution
> 
> The pinning feature will be removed. This removes the swift package pin and 
> swift package unpin commands, the --repin flag to swift package update, and 
> use of the Package.pins file.
> 
> In a future version of the package manager we may re-introduce pinning. If we 
> do, pins 

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

[Martin Waitz via swift-evolution]

Hi,

I think, it would be more natural to include the last newline.
Multi-line String literals are for multiple lines.
And each line ends in a \n. Otherwise it wouldn’t be a line.

Having
"""
line 1
"""
+
"""
line 2
"""
==
"""
line 1
line 2
"""

makes a lot of sense to me.

Or do we want to magically add a trailing newline everywhere as we do in 
print()?
Better change print to only add the newline when necessary! (e.g. by adding a 
new parameter which defaults to „auto“)

— 
Martin

> Am 19.04.2017 um 23:51 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> This is the natural way of text blocks. If you really need a blank line you 
> can add one at the start/end or alternatively use \n.
> 
> """
> 
> Foo  
> 
> """
> 
> // Equals "\nFoo\n"
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 19. April 2017 um 22:53:07, Vladimir.S via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> On 19.04.2017 23:03, Joe Groff via swift-evolution wrote:
>> > Proposal Link: 
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>> > 
>> > Hello Swift Community,
>> > 
>> > The review of SE-0168: "Multi-Line String Literals" ran from April 6...12, 
>> > 2017. The 
>> > proposal is *accepted with revisions. *Community feedback was largely 
>> > positive on the 
>> > idea, though the discussion highlighted several under-specified aspects.
>> > 
>> > - Questions arose about whether text could appear on the same line as the 
>> > opening and 
>> > closing delimiter, and how that would interact with the de-indentation 
>> > algorithm. The 
>> > core team feels that it is important to keep this feature focused on its 
>> > purpose of 
>> > allowing the easy embedding of pasted blocks of text, so *text inside the 
>> > literal on 
>> > the same line as either delimiter should be disallowed.*
>> > 
>> > // Allowed, equal to "foo\nbar"
>> > """
>> > foo
>> > bar
>> > """
>> 
>> Could you clarify, shouldn't this be equal to "foo\nbar\n" ? I.e. with 
>> trailing \n 
>> for "bar" line?
>> I didn't find any clarification about the injecting of line-end for last 
>> text 
>> line(not for the """ delimiter).
>> 
>> > 
>> > // Not allowed
>> > """foo
>> > bar
>> > """
>> > 
>> > // Not allowed
>> > """
>> > foo
>> > bar"""
>> > 
>> > This keeps the model straightforward to describe: a *single newline *is 
>> > always 
>> > stripped after the opening delimiter and before the closing one, and the 
>> > closing 
>> > delimiter's position always determines the indentation level of the entire 
>> > literal. 
>> > The core team acknowledges that single-line triple quoted strings have 
>> > other uses in 
>> > other languages, such as to avoid excessive escaping in a string that 
>> > contains lots 
>> > of literal quotes, but supporting that alongside the indentation-stripping 
>> > behavior 
>> > leads to a lot of subtlety, and there could be other solutions to the 
>> > escaping 
>> > problem down the line, such as raw strings. If nothing else, single-line 
>> > triple 
>> > quoted strings can be considered later as an additive feature.
>> > 
>> > - The core team also believes that *underindentation or inconsistent 
>> > tab/space usage 
>> > within the indentation should be an error.* Every line inside the literal 
>> > must begin 
>> > with the exact sequence of spaces and tabs that precedes the closing 
>> > delimiter.
>> > 
>> > """
>> > this is OK
>> > this is an error
>> > this is also an error
>> > under-indenting is an error too
>> > but you can go nuts after the indentation all you want
>> > you do you
>> > """
>> > 
>> > - The quoted string should *normalize newlines* to \n in the value of the 
>> > literal, 
>> > regardless of whether the source file uses \n (Unix), \r\n (Windows), or 
>> > \r (classic 
>> > Mac) line endings. Likewise, when the compiler strips the initial and 
>> > final newline 
>> > from the literal value, it will strip one of any of the \n, \r\n, or \r 
>> > line-ending 
>> > sequences from both ends of the literal.
>> > 
>> > // equal to "foo\nfoo\nfoo\nfoo"
>> > """^J
>> > foo^M^J
>> > foo^J
>> > foo^M
>> > foo^M
>> > """
>> > 
>> > - It should be clarified that *multiline strings support the same escapes 
>> > and 
>> > interpolations* as single-line strings. This allows a literal """ to be 
>> > written \""". 
>> > Discussion on the list raised the idea of allowing a line to end with \ to 
>> > "escape" 
>> > the newline and elide it from the value of the literal; the core team had 
>> > concerns 
>> > about only allowing that inside multi-line literals and felt that that 
>> > could also be 
>> > considered later as an additive feature.
>> > 
>> > Thanks John, Brent, and Tyler for the original proposal, and thanks to 
>> > everyone who 
>> > participated in the discussion!
>> > 
>> > -Joe
>> > Review Manager
>> > 
>> > 
>> > 

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

[Martin Waitz via swift-evolution]

Hey Brent,

thanks a lot for working on multi-line strings!

You were also talking about """ heredocs.
I really liked that idea.
Have you abandoned this concept?

Given that triple-quotes in Swift are already quite different from the Python 
version,
we could as well go one step further and introduce quoted here-docs.

E.g.:
print(""")
Hello world.
""" 

Is there any interest in something like this?
Should I invest some time in drafting a specification/proposal?

— Martin

> Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> :
> 
> Hey folks,
> 
> 
> We've revised the proposal again. The main difference: You no longer need an 
> initial newline to enable indentation stripping, and stripping no longer 
> removes that newline even if it is present. (Adrian Zubarev and I believe 
> some others argued for this.) We disagreed with this at first, but it made 
> more sense as we thought about it more. There are a few things we like about 
> it:
> 
>   1. The rules and algorithm are simpler.
>   2. It accommodates more coding styles.
>   3. Every non-escaped newline in the literal now creates a corresponding 
> newline in the resulting string.
>   4. it's easy to get the old behavior back by backslashing the leading 
> newline.
> 
> Unfortunately, I think this precludes stripping the trailing newline by 
> default, but I think this is ultimately a simpler and better approach than 
> the previous draft.
> 
> Other changes:
> 
>   * We realized we needed to make closing delimiter matching a little 
> more complicated if we wanted to allow one or two adjacent double-quote 
> characters that were part of the literal's contents. Oops.
>   * Tabs aren't actually allowed in ordinary string literals, so we now 
> explicitly mention that as a difference between the two types.
>   * We wrote some tests for the prototype (though they haven't been 
> updated for this new version yet). 
>   * There were some other wording changes, particularly in the 
> indentation stripping rationale, but nothing that affects the actual design.
> 
> I understand John is working on a new version of his toolchain so people can 
> play with the prototype. We hope to have that ready for you all soon.
> 
> Let us know what you think of the revisions!
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Martin Waitz via swift-evolution]

Well summarised Tino, I agree with all arguments.
Strong -1 from me, too.

> Am 11.04.2017 um 08:48 schrieb Tino Heth via swift-evolution 
> :
> 
> -1 (strong)
> 
> I think I've read all messages and haven't much to add — so just to sum up my 
> concerns in order:
> — It makes access control more complicated
> — It adds no power to the language
> — It diminishes the need for fileprivate without making it redundant
> — It is a mockery for SE-0025
> — It is a breaking change

If we want to encourage separating several aspects of one type into multiple 
extensions, then we should try a different approach.
When we allow to also introduce new member variables in extensions, then we 
could make them private while still keeping them local to the member functions 
which access them.

This approach has other downsides but I think we can cope with them.
Biggest disadvantage would be that the storage size is not immediately visible 
from the type definition.
We could require some marker (`partial class` / `extension class` / whatever) 
so that everybody can immediately see that there may be extensions with 
additional storage.

E.g.:

partial class Foo {}

extension Foo {
private var i = 0
func bar() {
print(i)
i += 1
}
}
extension Foo {
private var j = 1
func baz() {
print(j)
j -= 1
}
}

When we want any distinction between `private` and `fileprivate`, then these 
two extensions should not see each others private members.
Of course the other workaround would be to remove the distinction altogether 
and make private an alias for fileprivate.

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

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Martin Waitz via swift-evolution]

Hello,

> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
> Swift" begins now and runs through April 9, 2017. The revised proposal is 
> available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>  
> I
>  really like this version of the proposal with the backslash.

Have you also considered using the backslash when using the KeyPath?

E.g. `person\.bestFriendsName` instead of `person[keyPath: bestFriendsName]`

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

Re: [swift-evolution] [Pitch N+1] Submodules and Access Levels

[Martin Waitz via swift-evolution]

Ups accidentally sent an old draft, please disregard...

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

[swift-evolution] [Pitch N+1] Submodules and Access Levels

[Martin Waitz via swift-evolution]

Hi,

there are a lot of proposals floating around at the moment and I want to 
present my point of view.
I’ve read most of the discussion, but not everything and instead of replying to 
all the individual mail,
I’ll just add pitch N+1 into the mix. At the current level of discussion I hope 
that’s the best thing to do
in order to arrive at a consistent set of features.

Actually, I’m quite happy with the current set of access levels in Swift.
While I never was no fan of SE-0025, I can live with it.
Reverting it makes the language a little bit simpler, so in this mail I’ll just 
use `private`.
If you want to keep `fileprivate`, then just read every `private` as 
`fileprivate`.
I do like the new `open` so I’ll use it here.
If the community comes up with something different here, then also just replace 
it here.
I’ll try to concentrate on the interaction of modules and access levels,
which is more or less orthogonal to the concrete syntax.

What do we want to achieve?
 * Add more structure to packages and modules;
 * Allow some set of symbols which can be imported by a client but which are 
not imported by default;
 * Provide symbols to other modules/submodules of the same package without 
having to export them to the whole world.

My biggest point here is, that each entity should explicitly specify what get’s 
exported to clients.
I.e. symbols should not already be exported, just because they happen to be 
specified `public` in some module or submodule.

Something like this has already been proposed:
https://github.com/anandabits/swift-evolution/blob/scope-based-submodules/proposals/-scope-based-submodules.md
 

I very much prefer Brent’s alternative 


TBD
So this serves the same goal as `__init__.py` files in Python, but we wouldn’t 
require any magic name.
We could have a convention of using `init.swift` or 
`module.swift`/`package.swift`.
But at the end it would be up to the package author (because maybe she wants to 
use separate files to specify the exports).

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

Re: [swift-evolution] [Proposal] Typed throws

[Martin Waitz via swift-evolution]

> Am 18.02.2017 um 17:37 schrieb Matthew Johnson via swift-evolution 
> :
> 
> Thank you for taking the time to put this proposal together Anton!  I really 
> want to see typed throws make it into Swift 4.  This will be a very nice 
> feature to have.
> 
> I noticed that you included Joe Groff’s idea of replacing `rethrows` by 
> making every function have an error type which is by default `Never` for 
> non-throwing functions and `Error` for throwing functions that do not specify 
> an error type.  
> 
> I want to urge you to consider updating the proposal to take this direction 
> now rather than later.  This is a breaking change which means the longer we 
> wait the harder it is to justify.  In fact, I think incorporating the 
> breaking change could increase the chances of it being accepted for Swift 4.  
> Without that it is a purely additive change and those are not being given 
> priority in the Swift 4 release.

Seconded.
With typed throwing function parameters, it makes a lot of sense to be able to 
specify the rethrown type, based on the function given as parameter.

Now some bike-shedding:
I’m not really happy with the `throws(Type)` syntax, as it is too close to 
function parameters.
Why exactly is `throws Type` ambiguous?
The proposal mentions `Type -> Result` as potential thrown type, but functions 
cannot conform to `Error`.
Maybe we can instruct the parser to just allow simple type names between 
`throws` and the arrow `->`.

If that is not possible, we should at least try to find some visual hints to 
separate Error type from function parameters.

E.g. we could use brackets (think of: we are specialising the `throws`):

func foo() throws { … }

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

Re: [swift-evolution] [Review] SE-0154: Provide Custom Collections for Dictionary Keys and Values

[Martin Waitz via swift-evolution]

> The review of SE-0154 "Provide Custom Collections for Dictionary Keys and 
> Values" begins now and runs through February 22, 2017. The proposal is 
> available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md
>  
> 
> 
I haven’t followed the discussion too closely, so I’m sorry if this has already 
been answered:
What’s the rationale for selecting this proposal over the alternatives?
Especially with the upcoming Ownership Manifesto, value mutation may be solved 
much more easily.
Should we invest some more time into exploring the `modify` declaration for 
dictionaries?

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

Re: [swift-evolution] [swift-build-dev] SE-0152: Package Manager Tools Version

[Martin Waitz via swift-evolution]

Hello Rick,

thanks again for your time and to explain everything in so much detail! :-)

> Am 08.02.2017 um 18:34 schrieb Rick Ballard :
> 
> Ultimately, I think no one is thrilled with parsing the Swift tools version 
> out of a comment, but the feedback we've received so far (off-list) has 
> strongly favored that approach, and when we evaluated the tradeoffs vs. the 
> other approaches we considered, it seemed the best.

Yeah, I can follow your argumentation now.
And I don’t really have any better idea.
Thanks for the explanations.

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

Re: [swift-evolution] [swift-build-dev] SE-0151: Package Manager Swift Language Compatibility Version

[Martin Waitz via swift-evolution]

Hello Rick,

thanks for the explanation!

Am 2017-02-08 17:55, schrieb Rick Ballard:

I believe that the reason this was desired is because we expect that
package authors may wish to conditionally adopt new Swift 4 language
features without breaking their ability to build with Swift 3, using
conditional compilation blocks, e.g.

 #if swift(>=4.0)
 // Swift 4 code goes here
 #endif

With this proposal, you can do this by specifying [3, 4], in which
case the Swift 4 compiler will compile it as Swift 4 code, and use the
code inside the conditional compilation block, while the Swift 3
compiler will also be able to compile it (as Swift 3 code), skipping
the conditional compilation block.


That makes sense.

+1 :-)

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

Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

[Martin Waitz via swift-evolution]

Hi,

Am 2017-02-08 08:54, schrieb Dimitri Racordon via swift-evolution:

I guess allowing a list of versions to be specified is interesting for
continuous integration.
That would allow people to test their code under all intended supported 
version.


That is a valid use-case, but should be specified somewhere else.
In your `.travis.yml` (or whatever), you could specify to compile your 
package (and all dependencies)

with different versions of the swift tools.
However, all these different tool versions would still use the 
per-package `swiftLanguageVersion` to select the right compiler mode for 
each package.
This way, you can test that everything really builds and links with 
different tool versions.


I see no reason to include a list of versions in the manifest.
That only creates ambiguities ("works for me" if you happen to have the 
right tool version).


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

Re: [swift-evolution] SE-0152: Package Manager Tools Version

[Martin Waitz via swift-evolution]

Hi,

> The review of SE-0152 "Package Manager Tools Version" begins now and runs 
> through February 13, 2017.  The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md

From the proposal:
> Not changing this API would still leave the problem of figuring out which 
> Swift language compatibility version to interpret the manifest in. It's 
> possible that Package.swift manifests won't be significantly affected by 
> Swift language changes in Swift 4, and could mostly work in either language 
> compatibility mode without changes. However, we don't know whether that will 
> be the case, and it would be a significant risk to assume that it will be.

I really assume that the simple `Package.swift` files will be able to be 
compiled in swift 3 and swift 4 modes.
Do we really need this proposal now?
If we really encounter problems, we can always add it later.
So what exactly is the risk?

When we want to introduce it already now, I’d like to revisit the way the tool 
version is specified.

Can we _please_ not use a comment?
Comments are comments and should have no influence on how to parse the file.

By the way, in XML/HTML, the DTD/Doctype is not specified in a comment, but in 
a processor instruction (`` vs. ``).
So the XML example would more closely resemble something like `#swift(3.0)` in 
Swift.

Maybe the package manager could just grep for the `swiftLanguageVersion` 
specification?
This has to be specified by the package anyway.
We could simply specify that the swift compiler always uses the same mode for 
`Package.swift` and the rest of the sources,
and that the package manager obtains this version from the manifest without 
using the full Swift compiler.
I.e. this line would be fixed to some special syntax 
(`^\s*swiftLanguageVersion\s*:\s*(\d+)\s*,\s*$` or something).

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

Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

[Martin Waitz via swift-evolution]

Hello,

> The review of SE-0151 “Package Manager Swift Language Compatibility Version" 
> begins now and runs through February 13, 2017.  The proposal is available 
> here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md

I’ve one question regarding this proposal:
Why use the list `swiftLanguageVersions` instead of a simple 
`swiftLanguageVersion: Int = 3`?
What’s the advantage of being able to specify `[3,4]`?

If you already have a version 4 compiler, that one will be used anyway and if 
the source really is compatible with both versions,
it does not make any difference whether it will be run in version 3 or version 
4 mode.
So just setting it to `3` has the same effect, right?

I think it’s enough to specify something like „this source is intended to be 
compiled in swift version 3 mode“.
Most of the time, that’s all you can specify anyway, because you don’t know 
which future versions happen to be compatible.

— 
Martin
___
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

[Martin Waitz via swift-evolution]

Hi Boris,

> Am 31.01.2017 um 03:48 schrieb Rick Ballard <rball...@apple.com>:
> 
>> 
>> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> OK, you are right, branches can be helpful to have in the manifest.
>> But I’m still confident that we must not put explicit version information 
>> into it.
>> They belongs into the `Package.pins` file.
>> That is enough to get reproducible builds.
> 
> By "explicit version information", do you mean that you shouldn't put a git 
> revision hash in the manifest – only branches and version tags should be 
> acceptable?

yes exactly.
BTW: the more I think about it, the more I like the possibility to specify a 
branch in the manifest.

> I'd agree that the revision-based initializer is a marginal feature; normally 
> your package should depend on a version range or is tracking a branch. That 
> said, we can imagine that you might wind up needing to peg your dependency to 
> a specific revision that isn't a version tag, and not track a moving branch, 
> so this seemed like a fairly harmless feature to add for that case. What is 
> your objection about supporting that?
> 
> The decision about whether to put this information in your pins or in your 
> manifest should be driven by whether it's something your package requires, or 
> is just a workflow choice. If you just want to temporarily stick to a 
> specific revision of your dependency for workflow reasons, pinning is the 
> right way to do that. If, however, your package currently requires that 
> revision, and isn't going to work properly without it, then the manifest is 
> the right way to express that. You'd want that specification to stick even if 
> someone did `swift package update --repin` to get newer pinned revisions.

Well, I guess your package will also work with all commits following your 
special one.
Then I’d be enough to specify the branch: your special dependency version is 
already specified in the pins file and `swift package update` will only update 
to newer revisions.

So why would you (temporarily) want to stick to a specific version?
Because it happens to be the only compatible one at that time.
So even that is a workflow thing and not a „this is the one and only“.
And if you really really need to choose a specific commit which is in the past, 
then you can always create a special branch just for it.

I really like to have a clear separation between manifest and the pins file.
Otherwise I fear that inexperienced maintainers hard-code their dependencies to 
a specific version by accident.
I've seen too strict version specifications too often already (e.g. on npm) ;-)

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

Re: [swift-evolution] Strings in Swift 4

[Martin Waitz via swift-evolution]

Am 2017-01-26 12:49, schrieb Jonathan Hull via swift-evolution:

I had a realization a few weeks ago that regexes with capture groups
actually correspond to a type, where successive capture groups form a
tuple and recursive ones form arrays of the capture groups they
recurse (and ‘?’ conveniently forms an optional). For example the
type for the regex above would be (Int,String). Those types could be
pretty hairy for complex regexes though.

 let (id,name) = /(\d+): (\w+)/


Well, the regex would have a type of its own, but it would probably have 
a

generic Result parameter, which would include your `(Int,String)`.

You only get your (id,name) pair when match some input against that 
regex.


E.g. something like:

let r: Regex<(Int, String)> = /(\d+): (\w+)/
switch input {
case r(let id, let name): print("\(id): \(name)")
}

--
Martin
___
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

[Martin Waitz via swift-evolution]

Hello Boris,

> Am 25.01.2017 um 19:10 schrieb Boris Buegling :
>> But instead of hard-coding some version into the manifest, we should allow 
>> to specify dependencies without any version requirement.
>> The concrete branch/version specification should always be stored in the 
>> `Package.pins` file.
>> This way, we also don't have any problem with conflicting branch 
>> specifications.
> 
> While this is true for most packages, some have a development model where 
> they will always depend on a branch and never on a version. In that case, it 
> is more semantically correct to have the branch definition in the manifest, 
> otherwise the package would not be able to build without a pins file. 
> 
> This is especially true for the example from the proposal:
> 
> A -> (B:master, C:master) B -> D:branch1 C -> D:branch2
> 
> Since the pins file of packages B and C would not be considered when building 
> A, you would need to lift the pinning that is inherent to those packages up 
> to the pins file of A.

OK, you are right, branches can be helpful to have in the manifest.
But I’m still confident that we must not put explicit version information into 
it.
They belongs into the `Package.pins` file.
That is enough to get reproducible builds.

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

Re: [swift-evolution] "with" operator a la O'Caml?

[Martin Waitz via swift-evolution]

Am 2016-12-19 20:44, schrieb Erica Sadun via swift-evolution:

https://github.com/apple/swift-evolution/pull/346


-1
I don't like where this is heading.

If you want to introduce method cascading, then have a look at Dart.

E.g. the example from the pull request could be something like this:

let questionLabel = UILabel()
..textAlignment = .Center
..font = UIFont(name: "DnealianManuscript", size: 72)
..text = questionText

The expression could still work on a mutable struct/class which later 
becomes

immutable by using the `let` assignment.

The other example which silently creates a new instance is even worse.
If you want to do something like this, then please do it more 
explicitly.

E.g.:

let fewerFoos = foos.clone()
..remove(at: i)

Anyway, all of this is simply syntactic sugar and should wait...

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

Re: [swift-evolution] [Discussion] Generic protocols

[Martin Waitz via swift-evolution]

Am 2016-12-06 15:01, schrieb Daniel Leping via swift-evolution:


ConstructibleFromValue

Sounds way better to me than the second option considering we can't do
just

ConstructibleFromValue

Because of lack of order of associated types. So IMO either we
introduce order or we use == syntax.


we should be careful not to mix up associated types with actual generic 
type parameters.
When we introduce type parameters for protocols, they should be written 
within angle brackets.

Requirements for associated types should just stay after `where`.


What makes me worry is if this syntax is really the best one
possible:

typealias ConstructibleFrom = ConstructibleFromValue where
ValueType == V

I find it strange that such exact line with typealias and where is
required.


Why?
It introduces a new generic type which is equivalent to some protocol 
with additional requirements,

where the requirement on the associated type is parameterized.

Of course we should also allow to directly write parameterized 
protocols:


protocol ConstructibleFrom {
[...]
}

which can then be used with the type parameter:

struct Stuff: ConstructibleFrom {}

When we consider type parameters to be part of the protocol name,
then we can also support conformance to multple protocols which only 
differ in the type parameter.


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

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Martin Waitz via swift-evolution]

Hi,

Am 2016-12-01 11:08, schrieb Álvaro Monteiro via swift-evolution:
> - Typeprivate would allow to abandon the odd fileprivate. Access level
> would be constrained to swift constructs (structs, classes and
> extensions) and not to a compiler artifact (file).

Files are not compiler artifacts but design artifacts.
They group related stuff which was designed together and which should be 
reviewed together.

I really like `fileprivate` and how Swift currently handles access control.

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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

[Martin Waitz via swift-evolution]

Hello,

Am 2016-11-24 13:54, schrieb Alex Blewitt via swift-evolution:

At the moment, the proposal suggests having a secondary 'pins' file,
which exists to allow explicit dependencies to be checked in to
version control. This can be done at the moment, using a
Version(1,2,3) or range Version(1,2,3)...Version(1.2.3) in the
constraints.

What the proposal doesn't bring forward clearly is the versioning of
transitive dependencies, and whether or not those dependencies violate
the requirement constraints. For example, if A depends on B, and B
depends on C version 1.2.3+, can or should A pin C version 0.9.9? What
if A depends on B and D, both of which depend on different versions of
C that may be semantically equivalent (e.g. C version 1.2.3 and C
version 1.4.5)? This will come up more often than the 'fail to build'
approach outlined in the proposal.


be careful and do not mix up `Package.swift` and `Package.pins`.

Both are used for different things:
 * Package.swift is used to specify compatible versions of dependencies.
   These always apply.
   In your example above, a `swift update` would need to find a set of 
versions

   for B, C, and D where all these version requirements are met.
   Therefor, Package.swift ranges should be as broad as possible,
   to make it possible to find compatible versions.
 * Package.pins stores the current set of all (transitive) dependencies.
   It is stored in the toplevel project (A) and would pin one set of 
compatible

   (and hopefully tested) versions of B, C and D.
   This way you always get a clean state when you start working on A.

Then, when you run `swift package update` in A, it will try to find a 
newer set of

B, C, and D, by looking at all of the `Package.swift` files.
This new set will then be written to `Package.pins` so that everybody 
can benefit from the update.
It's important to not hard-code specific versions into `Package.swift` 
as this complicates the version resolution during update and could lead 
to the conflicting version requirements you describe.


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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

[Martin Waitz via swift-evolution]

> The review of "SE-0145: Package Manager Version Pinning" begins again after 
> revisions, starting now and running through November 28th. The proposal is 
> available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md
>  
> 
> 


> What is your evaluation of the proposal?

+1
I think this is an important change for the Swift package ecosystem.
Having reproducible builds by default is a big step forward.
Storing the version of all dependencies in version control and having an easy 
way to update them helps to reduce maintenance overhead of packages.

I have two comments / requests for improvement:
 * Having two completely separate modes (—enable-autopin vs. —disable-autopin) 
with a different semantic (e.g. for `swift update`) unnecessarily complicates 
the design. I understand that there are different use cases where packages have 
to be handled differently, however I think we should invest some more time on 
understanding these use cases (see below).
 * For me the term ‚pin‘ (just like ‚lock‘) implies that the version of pinned 
dependencies should be fixed and should therefore not be changed/updated. (But 
I’m not a native speaker, so you may have other associations here.) We should 
make clear that we *manage* dependencies and that dependencies should be easy 
to update even while they can be reproduced exactly.

Let’s look at the features of the proposal and how they can be used:
 * Defines two groups of dependencies (pinned vs. unpinned) where one group can 
be updated independently;
 * unpinned dependencies are automatically updated on clone, not just on update;
 * updates of unpinned dependencies are not considered a change in the 
package’s repository.
This can be used to easily update internal dependencies while keeping the same 
version of external dependencies.
Or to keep some difficult-to-update dependencies while constantly updating all 
the other dependencies.
Or to not create git changes for some selected dependencies.
You name it.

Basically it boils down to better control when and how dependencies are updated.
However, I’m not yet convinced that the proposed pinning system is the best way 
to do that.
Why only support two groups? Why these two modes of operation? Why not support 
a specific set of dependencies which are unmanaged while still tracking all new 
dependencies?

When we want to create groups of dependencies and handle them differently, then 
we should do that explicitly, by introducing groups which can be defined by the 
package maintainer.

E.g.:

swift package dependency  —group 

We could store each group in a file of its own (e.g. 
`Package-.versions` or whatever) and the maintainer could put each 
one under version control or not as he likes.

A whole group could be updated in one go:

swift package update —group internal

This could simulate the pinning as described in the proposal:

swift package dependency A —group unpinned
swift package dependency B —group pinned
echo Package-unpinned.versions > .gitignore
git add .gitignore Package-pinned.versions

Each group can be updated individually and the package maintainer can put this 
group under version control or not.
One group would have to be special to automatically include all new 
dependencies.
Other than that we would not need any special handling ala 
—repin/—enable-autopin. Groups could be defined to make updating related 
packages easier.
When needed, we could even set some groups to update automatically on build 
(not only on clone/update).
This could be useful for closely related packages. Why should clone be special 
anyways?


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

Yes.
Not managing the package dependencies would unnecessarily complicate package 
maintenance in the long term.


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

Yes.
Reproducible builds fit well into the safe-by-default approach of Swift.


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

I always hated `npm` and all those node packages which had overly restrictive 
dependency requirements.
I guess these were used in order to have more control about which version to 
use, but this resulted
in both packages which I could not build out of the box (because some 
dependencies changed),
and packages I could not update because of conflicting requirements.
Using loose version requirements + semver in `Package.swift` files together 
with exact versions
of all dependencies stored in the top-level package solves everything: you get 
reproducible builds
(based on `Package*.versions`) together with easy updates (based on all 
packages’ `Package.swift`).


> How much effort did you put into 

Re: [swift-evolution] guard let x = x

[Martin Waitz via swift-evolution]

Am 2016-11-04 06:55, schrieb Thorsten Seitz:

vars cannot be type narrowed as soon as concurrency comes into play.
That's why Ceylon restricts type narrowing to immutables.


Are you afraid that your variable gets changed under your feet and 
afterwards does not conform to the narrowed type any more?


In this case, you have to resort to locks or local copies anyway, even 
without type narrowing.
But you are right, type narrowing could transform a simple data race 
into a fatalError.


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

Re: [swift-evolution] guard let x = x

[Martin Waitz via swift-evolution]

Am 2016-11-03 09:17, schrieb Pyry Jahkola via swift-evolution:

As pleasing as it sounds*), the idea of type narrowing breaks down
badly if:

– the binding is implicit (without explicit extra syntax involved)
and
– what is bound happens to be mutable.

An example being:

 // VAR message: String?
 IF message != NIL { // magic turns 'message' into a non-optional
'String' here
 handleMessage(message)
 message = NIL // 'String' is not 'ExpressibleByNilLiteral'
 }

What magic would we require to still allow access to the Optional
interface of 'message' in that block? In other words, I'm afraid type
narrowing for Swift's enums (including Optional) isn't quite as simple
as that.


No magic would be required.
Just don't turn into non-optional but into implicitly unwrapped 
optional.


And only do so while the compiler can prove that it is non-nil.
I.e. after your `message = nil` line, it would be handled just like any 
other optional again.


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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Martin Waitz via swift-evolution]

> Am 03.11.2016 um 03:22 schrieb Daniel Duan <dan...@duan.org>:
> 
> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>>> What is your evaluation of the proposal?
>> 
>> +1 for using reproducible versions of dependencies
>> -1 for the actual proposal
>> 
>> My problem with this proposal is that it tries to please everybody by 
>> introducing options everywhere.
>> …
>> We should just drop all these problems and design a system which works for 
>> all use-cases
>> without having to manually pin dependencies.
> 
> The second half of the sentence contradicts with the first half. What if I 
> need to only pin some of the dependencies, have have the rest update 
> automatically?

Also, we should be really careful with our naming.
For me, pin or lock means: don’t touch it, keep this version.

If your use-case really is to keep a specific version, then well you should 
specify that as a requirement in your dependencies.
Then add this information (together with some comment why you absolutely need 
that version) to your `Package.swift`.

I want reproducible checkouts and builds, but I don’t want to make people feel 
that versions are set in stone.
We should encourage frequent updates. So we should not lock versions, we should 
just track and manage them.

If a package is actively maintained, then the maintainer will care about 
updating and adapting to changed dependencies.
If the package is not maintained any more, then it will not be adapted to 
changed dependencies anyway.
In this case it does not help to randomly break the build of dependent packages.

The best way out is to give dependent package maintainers the power to:
 * get enough information to see that there is a problem with a dependency
 * get enough time to be able to act accordingly (without having to rush 
because builds are already breaking everywhere)

With proper management of dependency versions, we can provide that.
Think of it as the git equivalent in package management :-)

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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Martin Waitz via swift-evolution]

> Am 03.11.2016 um 03:22 schrieb Daniel Duan <dan...@duan.org>:
> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>>> What is your evaluation of the proposal?
>> 
>> +1 for using reproducible versions of dependencies
>> -1 for the actual proposal
>> 
>> My problem with this proposal is that it tries to please everybody by 
>> introducing options everywhere.
>> …
>> We should just drop all these problems and design a system which works for 
>> all use-cases
>> without having to manually pin dependencies.
> 
> The second half of the sentence contradicts with the first half. What if I 
> need to only pin some of the dependencies, have have the rest update 
> automatically?

No contradiction:
Storing versions of all dependencies and having reproducible builds is 
independent from updating dependencies.
What you need is some automatic (e.g. driven by CI) system to update your 
dependencies.

When performing an update is the right time to select what you want to update.
Then you can also test the new set and document that you chose to update them.

Updates should always be explicit actions, not happening randomly at checkout 
time.

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

Re: [swift-evolution] [Review] SE-0143: Conditional Conformances

[Martin Waitz via swift-evolution]

Hi,

> The review of “Conditional Conformances” begins now and runs through October 
> 7.

What’s the status here?
My impression is that it’s quite uncontroversial and everybody can’t wait to 
see this implemented :-)

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

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Martin Waitz via swift-evolution]

> What is your evaluation of the proposal?

+1 for using reproducible versions of dependencies
-1 for the actual proposal

My problem with this proposal is that it tries to please everybody by 
introducing options everywhere.
I think we should try to build a system which is robust and works all of the 
time.

Being able to reproduce any build is a great value, no matter which package we 
are working on.
We should build our package management in a way that reproducible builds are 
the default.
Therefor I strongly propose to always store the exact version of all 
dependencies under
version control.

Just adding opt-ins (pinning of individual packages) creates new problems:
How should the user/maintainer select which packages to pin? How do we maintain 
this list?
E.g. even after the proposed `swift package pin —all`, you can end up with 
unpinned dependencies
after a `swift package --repin` when one dependency introduces some new 
sub-dependency.
Or should we also pin these sub-dependencies when the parent was already pinned?
But then what to do when the newly introduces sub-dependency was already part 
of the
closed set of all dependencies before, but was explicitly not pinned?

We should just drop all these problems and design a system which works for all 
use-cases
without having to manually pin dependencies.
Just store the version of all dependencies but make it easy to change/update 
them.
Of course, the used versions must be under control of the top-level package 
which is being built.
All the version information stored within dependencies may be a nice hint for 
the top-level
maintainer, but should not be used by the build system.
This way, we don’t have to differentiate between top-level and library packages.

I don’t think we have to be worried about weakening semver compatibility.
Library packages will be included by many top-level packages, each with their 
own
update cycle. Each update will be performed according to the semver 
specification.
CI systems also do not have to just build the current version, but could also 
use
an extra builder which first updates all dependencies and then does its tests.
Not versioning some dependencies does not provide any benefit here.
I also agree that it’s good to encouraging frequent updates, but we should find 
a different means.
We should make it easy to update dependencies, but leave it to each package 
maintainer to control
when and what to update.

If we don’t ‚pin‘ individual packages but simply store all versions, then I 
also propose
to use the name `Package.versions` for our new file.


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

yes.
Reproducible builds are important and should be supported by swift-pm.


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

Reproducible builds fit well into the safe-by-default approach of Swift.


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

I always hated `npm` and all those node packages which had overly restrictive 
dependency requirements.
I guess these were used in order to have more control about which version to 
use, but this resulted
in both packages which I could not build out of the box (because some 
dependencies changed),
and packages I could not update because of conflicting requirements.
Using loose version requirements + semver in `Package.swift` files together 
with exact versions
of all dependencies stored in the top-level package solves everything: you get 
reproducible builds
(based on `Package.versions`) together with easy updates (based on all 
packages’ `Package.versions`).


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

Read the proposal and the comments.

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

Re: [swift-evolution] guard let x = x

[Martin Waitz via swift-evolution]

Hi,

> Well, "guard x != nil" does not unwrap x. An additive proposal must make 
> clear the difference between testing if an optional is nil and unwrapping it.

Of course, we could specify something like: „after checking that some Optional 
is not nil, it is treated as an implicitly unwrapped optional“.

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

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

[Martin Waitz via swift-evolution]

Hi :)

> Daniel, it's all right, "There are only two hard things in Computer Science: 
> cache invalidation and naming things.“

That’s true :-).

So I throw another name into the ring: „Package.versions“.

I think the file should be named after what it contains: the versions of all 
dependencies.
This is used to get reproducible builds by always using the same pinned version.
But that is how the file is _used_, not what the file _is_.

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

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

[Martin Waitz via swift-evolution]

Hi,

> Suppose we had a semantic notion of which packages were intended to be 
> "top-level" versus used as a dependency, and we chose our defaults 
> accordingly (in this case, we would orient workflows towards pinning by 
> default in the top-level case, in the used as a dependency case we would 
> orient away from it, e.g. warning you if you checked it in). What would you 
> think of such a design?

What is wrong with checking in the versions of your dependencies even if you 
are not a top-level package?
That’s a great way to document which versions do work together and may be 
helpful for the maintainer of the top-level package which is depending on you 
(he can easily compare the version files to find problems).

I think we agree that `swift package` within the top-level project should not 
look at the Package version files of its dependencies.
So these files will not change anything for the top-level builds.

I really think that the easiest solution is to always store the versions of all 
dependencies in SCM.
Then have some `swift package update` to move all versions to the latest 
consistent set and we have everything we need.
Each package can be built reproducibly and can be managed independently.

If packages want to track their dependencies closely, then simply set up some 
CI which does the update automatically.
You could automatically create create ‚update‘-commits, test them and 
automatically merge them if you really want to.
But every update is documented and you can even bisect bugs which were 
introduced by the updates.
This is helpful both for top-level as well as for library projects.

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

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

[Martin Waitz via swift-evolution]

Hi,

When using a pattern match operator, I’d prefer to reverse its arguments:

if value matches pattern …

if result =~ .success(let x) { use(x) }

Being used to pattern matching in functional languages, I also do like our 
current syntax.
Using ~= together with `let` on the left looks very strange to me.

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Martin Waitz via swift-evolution]

Jonathan, that’s a really nice proposal! :-)

You also already achieved some points from your „future directions“ ;-)

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

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Martin Waitz via swift-evolution]

With the current difficulty to come up with an agreed set of identifies vs. 
operators, maybe we should really try to sidestep this issue entirely and study 
Jonathan Shapiro’s idea of using identifiers as operators.

— Martin

> Am 21.10.2016 um 22:10 schrieb Xiaodi Wu via swift-evolution 
> :
> 
> A few other thoughts:
> 
> * One of our (or at least my) overarching goals for this proposal is to 
> refine identifier and operator sets by moving away from an ad-hoc 
> character-by-character approach to a systematic treatment that relies on 
> well-defined criteria to select blocks of characters for inclusion. My 
> personal opinion is that reverting to discussions of individual characters, 
> such as the turned ampersand, means we're simply re-shuffling the current set 
> of identifier and operator characters to a different one, having failed to 
> discover any systematic basis for doing so. I think one of the strongest 
> parts of this proposal is the straight-up statement that identifier start 
> characters shall be IDC_Start and identifier continuation characters shall be 
> IDC_Continue, modulo a few ASCII characters that require special treatment in 
> Swift.
> 
> * Particularly if the community insists on emoji being identifiers, we will 
> have to critically evaluate how to proceed on that in tandem with operators, 
> because there exist emojified operators and arrows, and certain emoji are 
> encoded in blocks that are otherwise symbols, which Unicode is likely to deem 
> as operators in the future. Moreover, IIUC, certain codepoints can be either 
> emoji or non-emoji symbols and variant selectors can specify which they are, 
> but in the absence of a variant selector *either* the emoji or non-emoji 
> version can be correctly displayed depending on the platform. For some of 
> these, the non-emoji version is either clearly or plausible an operator 
> character. Therefore, without dealing *very* carefully with emoji and with 
> operators at the same time, we are failing to address a key motivation of 
> this proposal, which is to fix the incorrect separation between emoji 
> operators and emoji identifiers.
> 
> 

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

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt / use smaller Integer

[Martin Waitz via swift-evolution]

Hello,

It's just that a common data type wasting almost half the space seems 
inefficient. I guess this is also the reason why they didn't adopt 
optional integers widely in stdlib.


When someone is really interested in fitting an optional integer into 
one machine word,
then the best way would be to use a smaller integer type (e.g. Int32 
instead of Int64).
These also can be mapped well into Enums (a single reserved value does 
not help at all here).


There are some almost 64-bit integers (Builtin.Int60 .. Builtin.Int63).
Maybe something like this could also be provided for normal use?

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

Re: [swift-evolution] Mark protocol methods with their protocol

[Martin Waitz via swift-evolution]

Hi again,


Am 2016-09-27 16:51, schrieb Dave Abrahams via swift-evolution:

The cases where you find these kinds of exact collisions are so rare
(never in my career) that it's fine if some manual work is needed.


I agree that such accidental collisions are quite rare (especially
with the Swift way of naming methods which makes it quite easy to
describe the semantics of the function).


oh, sorry, I misread your statement.

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

Re: [swift-evolution] Mark protocol methods with their protocol

[Martin Waitz via swift-evolution]

Hi,

Am 2016-09-27 16:51, schrieb Dave Abrahams via swift-evolution:

The cases where you find these kinds of exact collisions are so rare
(never in my career) that it's fine if some manual work is needed.


I agree that such accidental collisions are quite rare (especially with 
the Swift way of naming methods which makes it quite easy to describe 
the semantics of the function).


However, I draw some other conclusion from it: I don't see why I should 
have to explicitly name the protocol in my methods. The method name is 
enough already to match it to the protocol.


We shouldn't complicate our language just for obscure cases where 
protocols accidentally collide.


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

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

[Martin Waitz via swift-evolution]

Hi,

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

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


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


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

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

extension MyStruct: Equatable {}

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

Re: [swift-evolution] Mark protocol methods with their protocol

[Martin Waitz via swift-evolution]

Hello :)

Am 2016-09-23 08:50, schrieb Rien:


> -- module A --
> class A {
>   func foo() {}
> }
>
> -- module B --
> protocol Foo {
>   func foo()
> }
> extension A: Foo {}

let c = A()

I’d say that you have two functions here:
A.foo() and A.Foo.foo()


No. Now (i.e. within module B) A conforms to Foo, using the already 
existing function.



Note that A.foo() was never intended to be used as an implementation
for protocol Foo, thus why should you be able to see it as such? That
imo is a bug in the language. Its not flexibility, it’s dangerous.


I disagree, this is the great thing about Swift.
It's exactly in the middle between Go's "everything is considered to 
implement a protocol if it happens to provide the right methods" and 
C++/younameit's "you have to know everything in advance and people are 
screwed if the library does not use the right protocols" style.


You can add protocol conformance to classes you don't control, but you 
have to explicitly declare this conformance.

I think this is exactly the right approach.

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

Re: [swift-evolution] Mark protocol methods with their protocol

[Martin Waitz via swift-evolution]

Hi,

isn't it perfectly fine to conform to multiple unrelated protocols which 
both require the same member?

Or to declare protocol conformance in some unrelated module?

Am 2016-09-22 07:15, schrieb Karl via swift-evolution:

I would like to make it a requirement if not inside a protocol
extension which declares a conformance, and actually build the
protocol name in to the member in an ABI-breaking way.


IMO, this is much too restrictive.
When we force the protocol name into the member, we make it impossible 
to conform to multiple protocols.

Well ok, we could create alias names for all protocols.
But often you don't know which protocols to conform to when you compile 
your module!


What about:

 -- module A --
 class A {
   func foo() {}
 }

 -- module B --
 protocol Foo {
   func foo()
 }
 extension A: Foo {}

What is your ABI name for A.foo()?

Let's keep it simple!
If a simple warning about unrelated methods in a protocol conformance 
extension solves 95% of our problem,
then we shouldn't overengineer and throw away all our flexibility just 
to be 100% explicit about which protocol uses which members.


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

Re: [swift-evolution] Mark protocol methods with their protocol

[Martin Waitz via swift-evolution]

Hello everybody,

Several suggestions are floating around about explicitly marking a 
method to implement a protocol requirement.


E.g.:


class Foo : Bar {
implement func foo() {...}
}


However, with extensions we can already do something very similar:

  class Foo {
  
  }
  extension Foo: Bar {
  func foo() {...}
  }

Maybe simply adding a new warning would already help.
Extensions which introduce new protocol conformances could be reserved 
for those methods which are already defined within the protocol. 
Whenever such an extension contains an unrecognized method, we could 
issue a warning.
Or maybe even an error, but we should allow private methods as an 
exception (for helper functions which are clearly not related to the 
protocol).


This way, when the programmer wants to make sure that her new method is 
used by a protocol then she can simply put that method in an extension.


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