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

On 2017-01-24 20:28:30 +, Daniel Dunbar via swift-evolution said: I am reposting this since the URLs were mangled in the original email. Hello Swift community, The review of SE-0149 “ Package Manager Support for Top of Tree development" begins now and runs through January 31, 2017. The

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

On 2017-01-24 18:18:07 +, Daniel Dunbar via swift-build-dev said: Hello Swift community, The review of SE-0150 “ Package Manager Support for branches" begins now and runs through January 31, 2017. The proposal is available here:

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

Excellent. I've added your name to the authors list on the gist. That is the version I'll be submitting to evolution soon. ~Robert Widmann 2017/01/25 0:58、thislooksfun のメッセージ: > No problem, it's been inactive for a couple weeks since I've been really > busy. And

Re: [swift-evolution] Reduce with inout

+1 Best so far. > On Jan 24, 2017, at 10:36 AM, Pyry Jahkola via swift-evolution > wrote: > > > Freak Show wrote: > >> Am I the only one who finds this incredibly ugly and hard to read? >> >> This is more or less solved by inject:into: idiom. There is no reason

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

> On 24 Jan 2017, at 19:18, Daniel Dunbar via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0150 “ Package Manager Support for branches" begins now and > runs through January 31, 2017. The proposal is available here: > > >

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

> • What is your evaluation of the proposal? It's a small improvement which will be very useful for a certain class of people/projects. I see no downsides. > • Is the problem being addressed significant enough to warrant a change > to Swift? Not significant for me, but quick

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

No problem, it's been inactive for a couple weeks since I've been really busy. And yeah, yours is more thorough. I didn't even consider adding a `testTargets` section. That alone is worth merging. -thislooksfun (tlf) > On Jan 24, 2017, at 11:55 PM, Robert Widmann

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

> >> On Jan 24, 2017, at 8:56 AM, Daniel Dunbar via swift-build-dev >> > wrote: >> >> Hello Swift community, >> >> The review of SE-0149 “ Package Manager Support for Top of Tree development" >> begins now and runs through January

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

I never agreed with removing it so this gets a bit fat +1 from me. Russ > On Jan 24, 2017, at 2:32 PM, Robert Widmann via swift-evolution > wrote: > > Hello Swift Community, > > Harlan Haskins and I have been working on libraries >

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

Oh, I'm sorry. I didn't know there was existing work in this space. Considering this proposal looks like it expands on your earlier work, would you like to sign on to this and merge the two efforts? ~Robert Widmann 2017/01/25 0:47、thislooksfun のメッセージ: > As the

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

As the author of the Add support for test-only dependencies thread, and the accompanying draft , this gets a big +1 from me.

Re: [swift-evolution] Strings in Swift 4

I'll use Karl's point here as a minor jumping-off point for a semi- related train of thought… I'm excited by the content of the original manifesto, including a powerful Unicode namespace and types. But as I've continued down the thread, I've had growing concern about modeling strings breadthwise

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 11:22 AM, Dave Abrahams via swift-evolution > wrote: >> >> How important is that, though? If you're using a `Substring`, you >> expect to keep the top-level `String` around and probably continue >> sharing storage with it, so you're probably

Re: [swift-evolution] Reduce with inout

Hmm, good point--none come to mind. On Tue, Jan 24, 2017 at 14:03 Matthew Johnson wrote: On Jan 24, 2017, at 1:27 PM, Xiaodi Wu wrote: Hmm, brainstorming here. Given the pervasive use of `with` to mean "this isn't accessible otherwise but inside

Re: [swift-evolution] Strings in Swift 4

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

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

No code would be broken. Like functions, case `bar(a:)` can be referred to as `bar` as long as there is no ambiguity. No existing code can have more than one case named bar. On Tue, Jan 24, 2017 at 19:17 Christopher Kornher wrote: > Sorry for not connecting the dots…yet another

Re: [swift-evolution] Strings in Swift 4

> Le 24 janv. 2017 à 11:33, Dave Abrahams via swift-evolution > a écrit : I've never seen anyone start a string with a combining character on purpose, >>> >>> It will occur as a byproduct of the process of attaching a diacritic >>> to a base character. >>

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Strings in Swift 4

> On Jan 22, 2017, at 15:40, Chris Lattner via swift-evolution > wrote: > Right, the only sensible semantics for a one sided range with an open end > point is that it goes to the end of the collection. I see a few different > potential colors to paint this bikeshed

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

Sorry for not connecting the dots…yet another example of why we need a better way to handle long discussions :) …and the dangers of multitasking, perhaps… I guess that this shows that having multiple cases with the same name, distinguished by the type of associated value, is possible without

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

It probably is a good idea. Perhaps the changes can be done in the Package.swift file but allow nesting of dependencies. Suppose your dependency is like this where P is your current project P --> A --> B Normally P we would describe its dependency on A while B would be abstracted away. In A,

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 10:14 AM, Chris Eidhof wrote: > > Hey Matthew, > > Do you have an example of doing parser combinators without FP? I'd be very > interest Hey Chris, looks like Dave provided a pretty good example of the kind of thing I was talking about. Does that

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

> On Jan 24, 2017, at 3:51 PM, Christopher Kornher wrote: > >> >> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I'm now confused who is arguing for what. Enums cases cannot have the

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

Yes, but *this* proposal is precisely to make the label part of the name. On Tue, Jan 24, 2017 at 17:51 Christopher Kornher wrote: > On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm now confused who is arguing for what.

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

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

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

Just to be clear (so may previous point may make more sense), the “name” in the function `func f(x: Int, y: Int) {}` is `f(x:y:)`. The name of `f(a: Int, b: Int) {}` does *not* share a name with the previous function. That’s what I refer to when I talk about names. I would not consider these

Re: [swift-evolution] Default Generic Arguments

> On 24 Jan 2017, at 05:10, Xiaodi Wu via swift-evolution > wrote: > > While it looks nicer without the angle brackets, that suggestion is > unresponsive to David's point that we need some way to distinguish defaulted > generic arguments from inferred generic

Re: [swift-evolution] Default Generic Arguments

As I replied above, this doesn't work IMO because omitted generic arguments are inferred, and that can't change without being hugely source-breaking. I think it's absolutely essential that adding a default to my library doesn't change the behavior of code that uses my library. That's currently

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

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

Re: [swift-evolution] Default Generic Arguments

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

Re: [swift-evolution] Default Generic Arguments

We are probably taking the wrong direction here and trying to solve the problem that does not need solving. We are discussing how to infer gereneric arguments in type declarations while we should not do that at all. Let me repeat Doug's examples: struct X { } func f1() -> X { return X() }

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

> On Jan 24, 2017, at 4:02 PM, Daniel Duan wrote: > > > > Daniel Duan > Sent from my iPhone > > On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > > wrote: > >> >> >> Daniel Duan >> Sent from my

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

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > wrote: > > > > Daniel Duan > Sent from my iPhone > >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution >> wrote: >>

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 7:52 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution >> > wrote: >> >> I agree that being able to implement

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

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution > wrote: > > I agree that this rule would be consistent with the handing of Swift > function signatures, but my proposal is self-consistent and: > > 1) It is

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Olivier Tardieu wrote: > Thanks for the great write-up! > > The manifesto recognizes the importance of machine processing and > performance. > I am surprised that there is no mention of any kind of "unsafe" strings or > string processing. > In general, Swift does an

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

Hello Swift Community, Harlan Haskins and I have been working on libraries to make interacting with LLVM and Clang’s APIs more elegant with native Swift interfaces. While writing up the packages we realized the package manager wouldn’t allow us to specify

Re: [swift-evolution] Default Generic Arguments

I like this approach as a first pass. It leaves room for other, more forgiving strategies later and is relatively easy to explain. On Tue, Jan 24, 2017 at 4:16 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 24, 2017, at 11:41, Alexis via swift-evolution < >

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

I agree that this rule would be consistent with the handing of Swift function signatures, but my proposal is self-consistent and: 1) It is more powerful, matching on the case name or not as required. 2) Is consistent with existing switches that ignore associated values 3) Is constant with

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

> On Jan 24, 2017, at 12:15 PM, Freak Show via swift-evolution > wrote: > > I do not see how you can consider standardizing ABI without first > standardizing the dynamic features and the desired programmatic interfaces to > them. > > We know that dynamic

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

> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution > wrote: > > Your example is only has only one case, which is not typical. Perhaps I am > missing something, but the only reason that I can imagine for having a case > with multiple ways to

Re: [swift-evolution] Default Generic Arguments

> On Jan 24, 2017, at 11:41, Alexis via swift-evolution > wrote: > > It’s worth noting that the question of “how do these defaults interact with > other defaults” is an issue that has left this feature dead in the water in > the Rust language despite being accepted

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

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

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

I am reposting this since the URLs were mangled in the original email. Hello Swift community, The review of SE-0149 “ Package Manager Support for Top of Tree development" begins now and runs through January 31, 2017. The proposal is available here:

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

Great suggestion. Done. > On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution > wrote: > > Ok, sounds logical. Might be worth adding that info to the proposal to make > it clear how ambiguity plays out. > >> On 24 Jan 2017, at 13:27, Xiaodi Wu

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

I do not see how you can consider standardizing ABI without first standardizing the dynamic features and the desired programmatic interfaces to them. We know that dynamic features need to come. They will impact everything. My personal ideal is a language that smoothly transitions from fully

Re: [swift-evolution] Reduce with inout

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

Re: [swift-evolution] Default Generic Arguments

It’s worth noting that the question of “how do these defaults interact with other defaults” is an issue that has left this feature dead in the water in the Rust language despite being accepted for inclusion two years ago. See

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

I agree that we shouldn't rush decisions but I feel like the emphasis of ABI stability has been a factor in discussing a number of proposals for Swift 4 and has been a core goal of this next major release. Seems strange to deemphasize it and its importance at this time. Below are some thoughts

Re: [swift-evolution] Strings in Swift 4

on Mon Jan 23 2017, Félix Cloutier wrote: >> Le 23 janv. 2017 à 20:45, Dave Abrahams a > écrit : >> >> >> >> >> >> On Jan 22, 2017, at 9:54 PM, Félix Cloutier > wrote: >> >>> > doesn't

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

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

Re: [swift-evolution] Strings in Swift 4

on Mon Jan 23 2017, Brent Royal-Gordon wrote: >> On Jan 21, 2017, at 3:49 AM, Brent Royal-Gordon >> wrote: > > I'm going to trim out the bits where my answer is an uninteresting "Good" or > "Okay, we'll leave that > for later" or

Re: [swift-evolution] Strings in Swift 4

on Sun Jan 22 2017, James Froggatt wrote: > Could we add subscript labels to the list of options? While keeping > the range syntax is appealing, I'm concerned it may cause confusion if > the operators are used out of context. > > The wording is up for debate, but

Re: [swift-evolution] Reduce with inout

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

Re: [swift-evolution] Reduce with inout

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

Re: [swift-evolution] Reduce with inout

> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution > wrote: > > > Freak Show wrote: > >> Am I the only one who finds this incredibly ugly and hard to read? >> >> This is more or less solved by inject:into: idiom. There is no reason for >> inout for

Re: [swift-evolution] Reduce with inout

> Freak Show wrote: > > Am I the only one who finds this incredibly ugly and hard to read? > > This is more or less solved by inject:into: idiom. There is no reason for > inout for this particular problem. Yeah, the original signature seems more useful. If you go all `inout` like Gwendal

Re: [swift-evolution] Strings in Swift 4

on Fri Jan 20 2017, Jonathan Hull wrote: >> On Jan 20, 2017, at 8:28 AM, Dave Abrahams wrote: >> >> >> >> >> >> >> >> >>> On Jan 20, 2017, at 5:48 AM, Jonathan Hull >> > wrote: >>> >>> Thanks for all the hard work! >>> >>>

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

Hello Swift community, The review of SE-0150 “ Package Manager Support for branches" begins now and runs through January 31, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md Reviews are an important

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Russ Bishop wrote: >> On Jan 19, 2017, at 6:56 PM, Ben Cohen via swift-evolution >> wrote: >> >> ### Formatting >> >> A full treatment of formatting is out of scope of this proposal, but >> we believe it's crucial for completing the text

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Chris Eidhof wrote: > I agree that being able to implement parsers in a nice way can be a huge > step forward in being really good at string processing. > > There are a couple of possibilities that come to mind directly: > > 1. Build parsers right into the language (like

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 12:35 AM, Russ Bishop wrote: > >> ## Open Questions >> >> ### Must `String` be limited to storing UTF-16 subset encodings? >> >> - The ability to handle `UTF-8`-encoded strings (models of `Unicode`) is not >> in >> question here; this is about what

Re: [swift-evolution] String Comparison

on Tue Jan 24 2017, Xiaodi Wu wrote: > I agree that there are refinements to operators that are needed, such as > the ability to pick which ones to import and more flexibility in shadowing > them, etc. But I think that's a whole nother discussion, and I rather think > that string comparison is

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

> On Jan 24, 2017, at 8:31 AM, Daniel Dunbar wrote: > >> >> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez > > wrote: >> >> Hi Daniel, >> >> I think this is an excellent idea! This would also solve the “local only”

Re: [swift-evolution] Reduce with inout

Am I the only one who finds this incredibly ugly and hard to read? This is more or less solved by inject:into: idiom. There is no reason for inout for this particular problem. > On Jan 24, 2017, at 06:43, Gwendal Roué via swift-evolution > wrote: > > But what if

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

(Sending this again because the first was accidentally offlist. Stupid reply-to headers.) +1 for Discourse from me as well. As for making a Swift-based site, server libraries do exist (Perfect, Vapor, Kitura, etc.), but afaik there is currently no built-in server support yet. -thislooksfun

Re: [swift-evolution] Reduce with inout

Yes, Matthew, I agree with you exactly on this. It's tricky. `copyOf` isn't ideal at all, but `mutating` is potentially misleading. Ah the difficulties of naming things. On Tue, Jan 24, 2017 at 09:15 Matthew Johnson wrote: > On Jan 24, 2017, at 8:12 AM, Chris Eidhof

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

> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez wrote: > > Hi Daniel, > > I think this is an excellent idea! This would also solve the “local only” > packages problem. >

Re: [swift-evolution] Strings in Swift 4

Hey Matthew, Do you have an example of doing parser combinators without FP? I'd be very interest On Tue, Jan 24, 2017 at 4:52 PM, Matthew Johnson wrote: > > On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution < > swift-evolution@swift.org> wrote: > > I agree

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution > wrote: > > I agree that being able to implement parsers in a nice way can be a huge step > forward in being really good at string processing. > > There are a couple of possibilities that come to mind

Re: [swift-evolution] Reduce with inout

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

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] Reduce with inout

I think you're all fighting against the language, and especially against `inout`. Because you try to copy and then mutate a value, instead of mutating it right away. I totally understand why: `inout` requires variable declared `var`, and the compiler won't auto-generate it for us. We try to

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 9:59 PM, Félix Cloutier via swift-evolution > wrote: > >> You can do it, but it trades one semantic problem for a usability problem, >> without solving all the semantic problems: you end up with a.count + b.count >> == (a+b).count, sure, but

Re: [swift-evolution] Reduce with inout

But if we want to add "copyOf" we should do that to every method that takes a struct? Also, what if you pass in an object? I see the concern, but I don't think adding `copyOf` will increase clarity. That said, I'm open to suggestions. On Tue, Jan 24, 2017 at 2:43 PM, Xiaodi Wu

Re: [swift-evolution] Reduce with inout

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

Re: [swift-evolution] Reduce with inout

Sent from my iPad > On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution > wrote: > > I've thought about it for a few days, and really like `reduce(mutating:_)`. I'm not a fan of this. It reads in a way that makes it seem like the parameter should be

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

Ok, sounds logical. Might be worth adding that info to the proposal to make it clear how ambiguity plays out. > On 24 Jan 2017, at 13:27, Xiaodi Wu wrote: > > I would imagine it would be logical to have it work just like it does now > with functions. If case bar is

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

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

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

I agree that there are refinements to operators that are needed, such as the ability to pick which ones to import and more flexibility in shadowing them, etc. But I think that's a whole nother discussion, and I rather think that string comparison is a distinctly poor use case for it. An operator

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

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

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

Breaking this into a different thread… One suggestion which I haven’t seen (maybe it is too crazy) is the idea of introducing shadowing of operators within a scope (similar to variables). Now this would need a TON of design work to make it actually work, but the gist would be: if blah

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

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

Re: [swift-evolution] Strings in Swift 4

That is quite tricky without breaking the ties Swift and Foundation/Standard Library have with Apple platforms or making the language needing better and better language lawyers to fully understand its specs. Sent from my iPhone > On 24 Jan 2017, at 09:35, Russ Bishop via swift-evolution >

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

> On Jan 23, 2017, at 9:14 PM, Erica Sadun via swift-evolution > wrote: > This was previously pitched. > > https://lists.swift.org/pipermail/swift-evolution/2015-December/000231.html > > >

Re: [swift-evolution] Strings in Swift 4

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

Re: [swift-evolution] Strings in Swift 4

Now that I think more about it, tainting strings with a comparison behavior may be a bad idea: // not a so good idea, after all let foo = "foo".comparison(case: .insensitive, locale: .current) Problems are: - Two strings tainted with the same comparison behavior should be

Re: [swift-evolution] Reduce with inout

Hi, Looks like there is a typo in the proposal: func reduce(mutating: A, _ combine: (inout A, Iterator.Element) -> ()) -> A { var result = initial This makes use of `initial` that is not defined, should be: func reduce(mutating initial: A, _ combine: (inout A,

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

Imho the major problem is that there's quite a lot confusion about what ABI stability actually means — and a lot uncertainty which proposals would actually affect it. People with more insight may prove me wrong, but I'll lay out my understanding in the next paragraph: It shouldn't be hard to

Re: [swift-evolution] Strings in Swift 4

I agree that being able to implement parsers in a nice way can be a huge step forward in being really good at string processing. There are a couple of possibilities that come to mind directly: 1. Build parsers right into the language (like Perl 6 grammars) 2. Provide a parser combinator language