Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > > What is your evaluation of the proposal? > -1 I would much

Re: [swift-evolution] Enums and Source Compatibility

> Am 21.12.2017 um 23:48 schrieb Andrew Bennett via swift-evolution > : > > Can you go into more detail about why the core team didn't like this? > public enum HomeworkExcuse { > case eatenByPet > case thoughtItWasDueNextWeek > default // NEW > } > > To me

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

Hi all, I am very much in favor of ‘switch x { … unknown: … }’ to express that I am expecting the cases to be complete at compile time so that I get notified when compiling against a newer version of the library where the enum has been extended. I consider not being able to test this a minor

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Am 06.12.2017 um 02:38 schrieb Chris Lattner : > > On Dec 5, 2017, at 11:13 AM, Thorsten Seitz wrote: >>> This example shows what many on this list don't believe: that any Swift >>> method or member access can fail. If the return value of this "get"

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution > : > >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution >> wrote: >> >> That’s a good principle. However, a dynamic member lookup is just a member >> lookup. By

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

+1 -Thorsten > Am 03.12.2017 um 21:20 schrieb Karl Wagner via swift-evolution > : > >> >> I believe that adding explicit syntax would be counterproductive to your >> goals, and would not make dynamic lookup syntax more clear. I assume that >> you would also want

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Am 03.12.2017 um 20:08 schrieb Magnus Ahltorp <m...@kth.se>: > >> 4 Dec. 2017 03:54 Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> The difference is that IUOs are marked by a "!“ whereas dynamic member

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Am 03.12.2017 um 18:36 schrieb Chris Lattner via swift-evolution > : > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

+1 to the concerns voiced by Doug, Matthew and others. I , too, would prefer a generator which generates a statically typed bridge instead of the dynamic lookup ature proposed which effectively undermines Swift's static type system. -Thorsten > Am 30.11.2017 um 15:15 schrieb Matthew Johnson

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

Shouldn't it be random.choose(from: 1...6) etc.? -Thorsten > Am 28.11.2017 um 00:20 schrieb Martin Waitz via swift-evolution > : > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

I like Tony's idea. Maybe the default argument functions could even take arguments with earlier parameters from the parameter list. -Thorsten > Am 25.11.2017 um 20:28 schrieb Tony Allevato via swift-evolution > : > >> On Fri, Nov 24, 2017 at 7:18 PM Xiaodi Wu via

Re: [swift-evolution] [Pitch] Raw mode string literals

> Am 24.11.2017 um 20:13 schrieb Xiaodi Wu via swift-evolution > : > >> On Thu, Nov 23, 2017 at 5:33 PM, Chris Lattner wrote: >>> On Nov 23, 2017, at 10:35 AM, Xiaodi Wu via swift-evolution >>> wrote: >>> This

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

+1 -Thorsten > Am 22.11.2017 um 18:48 schrieb Chris Lattner via swift-evolution > : > > IMO this is obvious and you should put it in. > > The process serves a purpose: to ensure the evolution of the language is > going in the right place, both directionally in an

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 22.11.2017 um 06:25 schrieb Douglas Gregor via swift-evolution > : > > > >>> On Nov 21, 2017, at 9:21 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 21.11.2017 um 07:32 schrieb Kelvin Ma : > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? Well, if I really had the need to use several geometry libraries at once I would have to convert,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution > : > > when SE-185 went through swift evolution, it was agreed that the next logical > step is synthesizing these conformances for tuple types, though it was left > out of the original proposal to

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> Am 21.11.2017 um 04:00 schrieb Chris Lattner via swift-evolution > : > > >> On Nov 12, 2017, at 8:52 PM, Slava Pestov via swift-evolution >> wrote: >> >> >> func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } > > +1,

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

+1 > Am 20.11.2017 um 21:32 schrieb Jon Shier via swift-evolution > : > > This is why I really like compact/compactMap. > >>> On Nov 20, 2017, at 3:31 PM, John McCall via swift-evolution >>> wrote: >>> On Nov 20, 2017, at 12:22 PM,

Re: [swift-evolution] Abstract methods

I mostly miss this (a.k.a. protected methods): "Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to

Re: [swift-evolution] [SPM] Roadmap?

+1 -Thorsten > Am 25.10.2017 um 21:47 schrieb Howard Lovatt via swift-evolution > : > > To clarify. I meant the infrastructure for IDE integration with Xcode as one > of the IDEs that used that infrastructure. > > -- Howard. > >> On 24 Oct 2017, at 11:26 pm,

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 19.10.2017 um 22:49 schrieb Adam Kemp <adam_k...@apple.com>: > >> >> On Oct 18, 2017, at 9:58 PM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> In your earlier email

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

Well, I have no problems with `flatMap` but then I am used to Monads. I would not rename that overload if there is any hope that we might get Monads sometime in the future but probably there is none (which is sad). So I would suggest `mapDroppingNil` or maybe `mapRejectingNil`. -Thorsten > Am

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>>> On Oct 18, 2017, at 4:14 PM, Thorsten Seitz <tseit...@icloud.com> wrote: >>> >>> >>>> Am 18.10.2017 um 22:04 schrieb Adam Kemp <adam_k...@apple.com>: >>>> >>>> >>>> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 19.10.2017 um 01:13 schrieb Adam Kemp : > > >> On Oct 18, 2017, at 3:38 PM, Thorsten Seitz > > wrote: >> >> Now this is not production code (hopefully) but it demonstrates the problem. > > A single StackOverflow post

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:04 schrieb Adam Kemp <adam_k...@apple.com>: > > >> On Oct 18, 2017, at 12:25 PM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Therefore having `elementsEqual` as API for unordered collec

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:36 schrieb Michael Ilseman : >> To get back to the topic at hand: I propose to differentiate between >> unordered and ordered collections because I think that this is an important >> distinction with tractable impact on algorithms (as shown above). The

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:31 schrieb Adam Kemp : > > >> On Oct 18, 2017, at 1:20 PM, David Sweeris > > wrote: >> >> How many bugs have been caused by floating point types violating the >> programmer's mental model of how

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 18.10.2017 um 22:36 schrieb Michael Ilseman : > > > >> On Oct 18, 2017, at 12:24 PM, Thorsten Seitz > > wrote: >> >>> >>> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution >>>

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 20:47 schrieb Michael Ilseman via swift-evolution > : > > > >> On Oct 17, 2017, at 10:15 AM, Kevin Nattinger via swift-evolution >> > wrote: >> >>> Because, in my analysis, the problem

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 14:46 schrieb Xiaodi Wu : > >> On Tue, Oct 17, 2017 at 01:03 Thorsten Seitz wrote: >> >> >>> Am 17.10.2017 um 01:43 schrieb Xiaodi Wu via swift-evolution >>> : >>> On Mon, Oct 16, 2017 at 6:10 PM,

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 14:44 schrieb Xiaodi Wu : > > >> On Tue, Oct 17, 2017 at 00:56 Thorsten Seitz wrote: >> >> >>> Am 17.10.2017 um 00:13 schrieb Xiaodi Wu : >>> >>> >>> On Mon, Oct 16, 2017 at 14:21 Thorsten Seitz

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Hi Gwendal, these are use cases for using indices as unordered references which certainly are useful. I was looking for use cases depending on the order exposed by Sequence, specifically use cases for elementsEqual. -Thorsten > Am 17.10.2017 um 09:03 schrieb Gwendal Roué

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 03:20 schrieb Xiaodi Wu via swift-evolution > : > >> On Mon, Oct 16, 2017 at 8:03 PM, David Sweeris wrote: >> >>> On Oct 16, 2017, at 1:07 PM, Xiaodi Wu wrote: >>> >>> On Mon, Oct 16, 2017 at

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 00:15 schrieb Adam Kemp : > > >>> On Oct 16, 2017, at 3:08 PM, Thorsten Seitz wrote: >>> >>> 2. It’s generally useful to be able to ask if two objects that you can >>> iterate over are equal by comparing the elements in the order

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 17.10.2017 um 01:43 schrieb Xiaodi Wu via swift-evolution > : > >> On Mon, Oct 16, 2017 at 6:10 PM, Jonathan Hull wrote: >> >>> On Oct 16, 2017, at 1:05 PM, Xiaodi Wu wrote: >>> >>> On Mon, Oct 16, 2017 at 10:49

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Even worse, Set([5,4,3,2,1]) will probably return false although it contains the same elements. -Thorsten > Am 17.10.2017 um 01:40 schrieb Jonathan Hull via swift-evolution > : > > To expand on this, Set([1,2,3,4,5]).hasPrefix([1,2,3]) currently returns > true.

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 22:29 schrieb Adam Kemp <adam_k...@apple.com>: > > > >> On Oct 16, 2017, at 12:35 PM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> IMHO `elements

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 19:42 schrieb BJ Homer <bjho...@gmail.com>: > >> On Oct 16, 2017, at 8:20 AM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> Am 16.10.2017 um 07:19 schrieb

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 18:19 schrieb Michael Ilseman <milse...@apple.com>: > > > >> On Oct 16, 2017, at 7:20 AM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 17:49 schrieb Jonathan Hull via swift-evolution > : > > >> On Oct 16, 2017, at 7:20 AM, Xiaodi Wu > > wrote: >> >> To start with, the one you gave as an example at the beginning of this >>

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 16:20 schrieb Xiaodi Wu via swift-evolution > : > > > On Mon, Oct 16, 2017 at 05:48 Jonathan Hull > wrote: > >> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu > >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

>> Am 16.10.2017 um 07:19 schrieb Xiaodi Wu : >> >> On Sun, Oct 15, 2017 at 11:57 PM, Thorsten Seitz wrote: >> >> >>> Am 16.10.2017 um 00:41 schrieb Xiaodi Wu via swift-evolution >>> : >>> >>> On Sun, Oct 15, 2017 at 2:32

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 04:36 schrieb Jonathan Hull via swift-evolution > : > > Ok, just to summarize our options so far (in order of effort & theoretical > effectiveness): > > 1) Do nothing - This is the easiest thing to do, but it won’t fix any problems > > 2) Rename

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 00:46 schrieb Xiaodi Wu : > > On Sun, Oct 15, 2017 at 2:39 PM, Kevin Nattinger wrote: >>> […] >>> Swift's Sequence protocol does not require the order of iteration to >>> "convey any meaning"; it doesn't even require it to be

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 16.10.2017 um 00:41 schrieb Xiaodi Wu via swift-evolution > : > > On Sun, Oct 15, 2017 at 2:32 PM, Kevin Nattinger wrote: >>> […] >>> Sets, as a mathematical concept, have no intrinsic order. However, >>> instances of `Set`, which can be

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 15.10.2017 um 21:22 schrieb Xiaodi Wu : > > > On Sun, Oct 15, 2017 at 14:14 Thorsten Seitz wrote: >>> Am 15.10.2017 um 10:38 schrieb Xiaodi Wu via swift-evolution >>> : >>> On Sun, Oct 15, 2017 at 2:29 AM, Kevin

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> Am 15.10.2017 um 10:38 schrieb Xiaodi Wu via swift-evolution > : > > On Sun, Oct 15, 2017 at 2:29 AM, Kevin Nattinger > wrote: > >> On Oct 14, 2017, at 7:54 PM, Xiaodi Wu >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Well said, Kevin! I agree to all points you made. Yes, a Set has no intrinsic order, just an iteration over a set has. And the latter does not even have to be stable. Let’s split Iterable off Sequence. -Thorsten > Am 14.10.2017 um 09:28 schrieb Kevin Nattinger via swift-evolution >

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

Totally agree with Kevin’s analysis. I always thought „Sequence“ a very misleading name for an Iterable. I wouldn’t mind the breakage at all. -Thorsten > Am 13.10.2017 um 06:57 schrieb Kevin Nattinger via swift-evolution > : > > –∞ > > 1. I strongly object to the

Re: [swift-evolution] Re-pitch: remove(where:)

`formFilter` strongly implies that the result is a filter, so this would be a very bad choice. i do not follow the argument that it makes sense to just concatenate `form` and the non-mutating method name. The precedence set by `formUnion` is not a good one but at least there it makes sense

Re: [swift-evolution] (core library) modern URL types

malltalk_AcmDL.pdf > > Thanks, > Jon > >> On Sep 20, 2017, at 10:03 PM, Thorsten Seitz via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> Am 24.08.2017 um 23:07 schrieb Eagle Offshore via swift-evolution >>> <swift-e

Re: [swift-evolution] (core library) modern URL types

> Am 24.08.2017 um 23:07 schrieb Eagle Offshore via swift-evolution > : > > I liked the polymorphic identifiers paper presented at Dynamic Languages > Symposium 2013. > > http://dl.acm.org/citation.cfm?doid=2508168.2508169 > > There's a lot of power in URI's that

Re: [swift-evolution] (core library) modern URL types

Totally agree! -Thorsten > Am 24.08.2017 um 20:06 schrieb Jean-Daniel via swift-evolution > : > > Yes, and a URI class that don’t provide any FS operations, but only take care > of proper URI parsing and building. > >> Le 23 août 2017 à 12:03, Jakob Egger via

Re: [swift-evolution] (core library) modern URL types

+1 -Thorsten > Am 23.08.2017 um 12:03 schrieb Jakob Egger via swift-evolution > : > > I would absolutely love to see an API like AbsolutePath / RelativePath for > file system operations! > >> On 22. Aug 2017, at 21:02, Dave DeLong via swift-evolution >>

Re: [swift-evolution] Find/split on sub-string/sequence

Good idea! -Thorsten > Am 07.09.2017 um 09:21 schrieb Daryle Walker via swift-evolution > : > > There are sequence/collection/string methods to find an element/character or > split a container on an element or one of a set of elements. But I haven't > noticed

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> Am 12.09.2017 um 21:18 schrieb Adam Kemp : > >> On Sep 11, 2017, at 9:56 PM, Thorsten Seitz wrote: >> >> My hope would be for something along these lines: >> >> func createDownloadTasks(for urls: [URL]) -> [async Data] { >> return urls.map { url

Re: [swift-evolution] await keyword "scope"

Totally agree with Adam. > Am 13.09.2017 um 00:39 schrieb Adam Kemp via swift-evolution > : > >> On Sep 12, 2017, at 2:40 PM, Wallacy wrote: >> >> "No, the order of execution is well-defined. The problem isn’t in which >> order the arguments are

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

Good arguments, Tony, you have convinced me on all points. Transient is the way to go. Thank you for your patience! -Thorsten > Am 12.09.2017 um 16:38 schrieb Tony Allevato via swift-evolution > : > > > >> On Mon, Sep 11, 2017 at 10:05 PM Gwendal Roué

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

My hope would be for something along these lines: func createDownloadTasks(for urls: [URL]) -> [async Data] { return urls.map { url in async downloadResource(url) } } func await(all tasks: [async Data]) async -> [Data] { return tasks.map { task in await task } } -Thorsten > Am

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

I think I do understand Haravikk's argument (actually it seems quite straightforward to me). An example should be: struct Foo : Equatable { var x: Int var cachedLabel: String? = nil init(x: Int) { self.x = x } mutating func label() { if let label =

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 21.08.2017 um 22:32 schrieb Brent Royal-Gordon via swift-evolution > : > >> On Aug 21, 2017, at 12:41 PM, Wallacy via swift-evolution >> wrote: >> >> Based on these same concerns, how to do this using async/await ? >> >> func

Re: [swift-evolution] [Concurrency] async/await + actors

If I understand correctly this queue/thread hopping problem arises because we do not want `await` to block. If `await` would block we would trivially stay in the same thread/on the same queue. Actually I think that the mental model and the semantics should work as if `await` did block. Anything

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 20.08.2017 um 04:38 schrieb Thomas via swift-evolution > : > > >>> On 20 Aug 2017, at 03:36, Brent Royal-Gordon wrote: >>> On Aug 19, 2017, at 2:25 AM, Thomas wrote: I think we need to be a little

Re: [swift-evolution] [Concurrency] async/await + actors

First off, I’m still catching up with all those (very welcome :-) threads about concurrency, so bear with me if I’m commenting on topics that have been settled in the meantime. > Am 18.08.2017 um 17:13 schrieb Johannes Weiß via swift-evolution > : > > Hi Chris &

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 21.08.2017 um 22:09 schrieb Karim Nassar via swift-evolution > : > > Thought about it in more depth, and I’m now firmly in the camp of: > ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the > slight call-site reduction in typed

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

> Am 22.04.2017 um 21:27 schrieb Xiaodi Wu : > > On Sat, Apr 22, 2017 at 12:57 PM, Thorsten Seitz > wrote: > >> Am 22.04.2017 um 17:08 schrieb Xiaodi Wu > >: >> >> On

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

+1 Extensions are a great feature and I’m really glad that Swift has them. Conflicts should be handled by improving import and disambiguation features like Xiaodi says which is useful for other cases as well. -Thorsten > Am 18.04.2017 um 03:47 schrieb Xiaodi Wu via swift-evolution >

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

> Am 22.04.2017 um 17:08 schrieb Xiaodi Wu : > > On Sat, Apr 22, 2017 at 3:21 AM, Thorsten Seitz > wrote: > >> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution >>

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

> Am 21.04.2017 um 20:48 schrieb Xiaodi Wu via swift-evolution > : > > On Fri, Apr 21, 2017 at 1:45 PM, Erica Sadun > wrote: > >> On Apr 21, 2017, at 12:40 PM, Xiaodi Wu via swift-evolution >>

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

> Am 22.04.2017 um 05:41 schrieb BJ Homer via swift-evolution > : > > The "Access Control" section of the Swift 3 book says the following: > >> You can mark an extension with an explicit access-level modifier (for >> example, private extension) to set a new default

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

> Am 21.04.2017 um 15:45 schrieb David Hart via swift-evolution > : > > >> On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution >> wrote: >> >> Dear Xiaodi Wu, why do you always have to be offensive in a way of >> questioning

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

I have to say that — while the concerns of the others are certainly valid, especially with regards to namespacing — I do like this idea, especially how it unifies access control of lexical scopes with that of types and friends. -Thorsten > Am 14.04.2017 um 22:58 schrieb Erica Sadun via

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

> Am 15.04.2017 um 16:46 schrieb Ricardo Parada <rpar...@mac.com>: > > Reply inline. > > On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> A

Re: [swift-evolution] [Review] SE-0166: Swift Archival & Serialization

> Am 13.04.2017 um 06:20 schrieb Brent Royal-Gordon via swift-evolution > : > >> On Apr 12, 2017, at 2:12 PM, Zach Waldowski via swift-evolution >> > wrote: >> >> I want to disagree with this is strongly

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

> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution > : > > I disagree, the examples you have provided are more complicated than you > might think they are. Before explaining why, I’m going to make things clear > about the ‘two modes’ of the

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

> Am 14.04.2017 um 23:35 schrieb BJ Homer : > > >> Consider these two examples: >> >> let string_1 = """foo""" >> >> >> let string_2 = """ >> foo >> """ >> What’s the intuitive result you’d expect without taking all the long talk >> from the list into account? >>

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

I agree with Adrian that trailing whitespace which is not followed by a backslash should be stripped, because it is not visible otherwise (unlike in a normal string). -Thorsten > Am 13.04.2017 um 15:32 schrieb Adrian Zubarev via swift-evolution > : > >

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

> Am 13.04.2017 um 00:20 schrieb Brent Royal-Gordon : > > Wow, maybe I shouldn't have slept. :-) > > Okay, let's deal with trailing newline first. I'm *very* confident that > trailing newlines should be kept by default. This opinion comes from lots of > practical

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

> 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

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

rsten > > > On Wed, Apr 12, 2017 at 07:47 Thorsten Seitz via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Am 12.04.2017 um 14:36 schrieb Ricardo Parada via swift-evolution >> <swift-evolution@swift.org <mail

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

hing we’ve >>> asked for, it’s easy, it has both leading and trailing precision and >>> implicit new lines where needed. >>> >>> >>> >>> -- >>> Adrian Zubarev >>> Sent with Airmail >>> >>> Am 12. April 2017 u

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

nd >> implicit new lines where needed. >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution >> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>)

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

cit e.g. #trimLeft(“”"a literal""") >>> >>> Perhaps we can find common ground on 1) and 2) and even 3) with a view to >>> resubmitting if there is time. Seems mostly like we just need to discuss >>> the delimiter further and decide whether t

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

> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution > : > > Great explanation thank you Brent. I’m convinced about the closing delimiter > now. =) > > If I understood correctly what Xiaodi Wu meant in his reply, then we could > simplify the whole

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

. > > With respect to 4) I’m updating > https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md> > as the proposal i

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

> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > > What is your evaluation of the proposal? +1 in general BUT I absolutely dislike having to escape a key path with `\` which

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

> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > > What is your evaluation of the proposal? +1 My foremost expectation from multiline

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

+1 > Am 03.04.2017 um 10:29 schrieb Daniel Duan via swift-evolution > : > > I want to retract my nitpickings on argument labels; `all(equal:)` and > `all(match:)` are the best names for these methods. > > things all match condition? > things all equal value? > > If

Re: [swift-evolution] Type-based ‘private’ access within a file

> Am 04.04.2017 um 01:55 schrieb Brent Royal-Gordon via swift-evolution > : > >>> On Apr 3, 2017, at 3:07 PM, David Hart wrote: >>> >>> On 3 Apr 2017, at 23:55, Brent Royal-Gordon wrote: >>> >>> If that's the case, I

Re: [swift-evolution] multi-line string literals.

> Am 03.04.2017 um 17:09 schrieb Ricardo Parada via swift-evolution > : > > Hi Adrian, > > I'm not sure if I am understanding what you are saying. > > To me a multi-line string literal is not about continuing a "very long > string" into the next line. > > To me

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

nums.allSatisfy { $0 % 2 == 0 } -Thorsten > Am 03.04.2017 um 03:06 schrieb Ricardo Parada via swift-evolution > : > > I think the problem would be that if you want to use it with a trailing > closure then it becomes misleading: > > nums.contains { $0 % 2 == 0 } >

Re: [swift-evolution] for-else syntax

I would prefer `ifNone:` instead of `otherwise` as it makes the semantics clearer IMHO. -Thorsten > Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution > : > > >> On 2 Feb 2017, at 13:44, Derrick Ho wrote: >> >> Maybe we can add a

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

While I'm not really happy with the mailing list, this is mostly due to restrictions of iOS Mail which makes keeping track of relevant threads and filtering out threads I'm not interested in difficult. The mailing list has one important advantage over a web interface: most of my reading

Re: [swift-evolution] Strings in Swift 4

If I understand correctly, `1...` is not a Range but a RangeExpression which should not conform to Sequence and would need to be provided with a value for its open end to turn it into a Range. Subscript would provide the last valid index in your first example and for your second example you

Re: [swift-evolution] Strings in Swift 4

> Am 24.01.2017 um 20:28 schrieb Dave Abrahams via swift-evolution > : > > >> on Sun Jan 22 2017, James Froggatt wrote: >> >> Could we add subscript labels to the list of options? While keeping >> the range syntax is appealing, I'm

Re: [swift-evolution] Strings in Swift 4

I prefer c[i...] After all, why should it mean c[i...c.endIndex] and not c[i...c.lastIndex]? With the latter interpretation it is not just typographically nicer but also consistent. -Thorsten Am 23.01.2017 um 00:40 schrieb Chris Lattner via swift-evolution : >>

Re: [swift-evolution] Generic Subscripts

> Am 23.01.2017 um 18:26 schrieb Gwendal Roué : > >> Where generic subscripts are concerned, there are a couple of different >> things to express: >> - Generic parameter (I can understand various co-ordinates for the data) >> - Generic return type (I

Re: [swift-evolution] Generic Subscripts

> Am 14.01.2017 um 14:50 schrieb Gwendal Roué via swift-evolution > : > Where generic subscripts are concerned, there are a couple of different things to express: - Generic parameter (I can understand various co-ordinates for the data) - Generic

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

vars cannot be type narrowed as soon as concurrency comes into play. That's why Ceylon restricts type narrowing to immutables. -Thorsten > Am 03.11.2016 um 09:52 schrieb Martin Waitz via swift-evolution > : > > Am 2016-11-03 09:17, schrieb Pyry Jahkola via

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Has anybody thought about the semantic issues of out-of-module extensions with stored properties apart from the implementation issues? Such properties could potentially wreak havoc with the semantics of the type being extended. How would these properties play nice with an existing definition

  1   2   3   4   >