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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> * 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

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

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

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

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,

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

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 """

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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: > > >

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

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: >> >&

Re: [swift-evolution] Strings in Swift 4

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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?

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

> 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 reproducib

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

> 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

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

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

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

> 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

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

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

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

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.

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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

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

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 { }