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

Thanks Jacob. It also looks like one can initiate a new topic via email — does that sound correct? > On Jan 25, 2017, at 10:28 PM, Jacob Bandes-Storch wrote: > > Discourse provides: > > - Reply to a topic via email: >

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

We don't have support for inlining package dependencies in targets (see the comment in above manifest example). I suggested that we turn this proposal into adding that feature. On Thu, 26 Jan 2017 at 1:04 PM, David Hart wrote: > I'm confused. I've followed this from afar as I

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

I'm confused. I've followed this from afar as I don't have much SwiftPM experience, but if that is true, what's the point of the proposal? > On 26 Jan 2017, at 08:12, Ankit Agarwal via swift-evolution > wrote: > > The test targets are *not* compiled when you run

Re: [swift-evolution] Annotation of Warnings/Errors

OTOH, looking at fixit and error messages can also aid in understanding Swift better. Seeing what happens when it happens is something I find quite useful. Not that I have anything against the proposal, but I do wonder if that is the best usage of available resources. A BIG OT warning: If

Re: [swift-evolution] Strings in Swift 4

If you haven’t seen Perl 6 grammars, I highly suggest taking a look. https://perl6advent.wordpress.com/2009/12/21/day-21-grammars-and-actions/ https://docs.perl6.org/language/grammars

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

On Thu, Jan 26, 2017 at 6:37 AM, thislooksfun via swift-evolution < swift-evolution@swift.org> wrote: > I still much prefer 'testDependencies/Targets'. You seem to be confusing > this proposal with the (already accepted) Package Manager Product > Definitions >

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] [Discussion] mailing list alternative

> On Jan 25, 2017, at 9:45 PM, Jacob Bandes-Storch wrote: > >> On Wed, Jan 25, 2017 at 12:05 PM, Ted Kremenek via swift-evolution >> wrote: >> ... >> >> So in short, using mailing lists specifically is not sacred — we can change >> what we use

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

Discourse provides: - Reply to a topic via email: https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099 - "Mailing list mode": https://discourse.mcneel.com/t/mailing-list-mode-for-discourse/5763 & https://meta.discourse.org/t/what-is-mailing-list-mode/46008 On Wed, Jan 25, 2017 at

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

I had this same question in my mind — especially if one can reply to an email and it posts back to the forum. The mailing list model works well for those who want to get the entire feed of traffic, and easily monitor which threads they want to follow/read using the standard affordances in

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

...never mind, figured out how to download it — https://meta.discourse.org/t/import-mailman-archives-into-discourse/18537/11 On Wed, Jan 25, 2017 at 9:53 PM, Jacob Bandes-Storch wrote: > On Wed, Jan 25, 2017 at 1:32 PM, Douglas Gregor via swift-evolution < >

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

On Wed, Jan 25, 2017 at 1:32 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > I have no problem with the project moving to forums instead of the Mailman > mailing

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 5:49 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jan 25, 2017, at 1:10 PM, Dave Abrahams via swift-evolution >> > wrote: >> >>> I also prefer #1. It’s a shame that

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

On Wed, Jan 25, 2017 at 12:05 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > ... > > So in short, using mailing lists specifically is not sacred — we can > change what we use for our community discussions. I just want an objective > evaluation of the needs the mailing

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

On Wed, Jan 25, 2017 at 8:28 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 25, 2017, at 6:57 PM, Xiaodi Wu wrote: > > Signing up for mailing lists is straightforward, yes—but that’s only a >> small part of it. Signing up for a mailing

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

Can a forum be configured to send each new post to the mailing list with proper subject line? If so, that would enable a best-of-both-worlds scenario—or at least the ability to dip our toes in a forum to see if it works, while still showing everything on-list. Nevin On Wed, Jan 25, 2017 at

Re: [swift-evolution] Strings in Swift 4

On Jan 25, 2017, at 7:32 PM, Dave Abrahams wrote: >> There are two important use cases for regex's: the literal case >> (e.g. /aa+b*/) and the dynamically computed case. The former is >> really what we’re talking about here, the latter should obviously be >> handled with

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

> On Jan 25, 2017, at 6:57 PM, Xiaodi Wu wrote: > >> Signing up for mailing lists is straightforward, yes—but that’s only a small >> part of it. Signing up for a mailing list is a *commitment.* Once you do it, >> your inbox will be inundated with mailing list posts,

Re: [swift-evolution] Strings in Swift 4

> Le 25 janv. 2017 à 13:08, Ben Cohen a écrit : >> Okay, so I'm serializing two strings "a" and "b", and later on I want to >> deserialize them. I control "a", and the user controls "b". I know that I'll >> never have a comma in "a", so one obvious way to serialize the two

Re: [swift-evolution] Strings in Swift 4

on Wed Jan 25 2017, Ben Rimmington wrote: >> On 25 Jan 2017, Dave Abrahams wrote: >> >>> on Tue Jan 24 2017, Ben Rimmington wrote: >>> >>> Could you include the latest ICU alongside the Swift standard library? >> >> To what end? > > When iOS 10 and macOS 10.12 were released (2016-09-13), >

Re: [swift-evolution] Annotation of Warnings/Errors

This sounds wonderful. It’s extremely common, in my experience with junior developers, for them to blindly accept Xcode’s suggestions—and why wouldn’t they? Delaying the display would certainly be a benefit for everyone, but especially people who are just learning Swift. Jeff Kelley

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Chris Lattner wrote: > On Jan 24, 2017, at 12: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. > > +1 from

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

On Wed, Jan 25, 2017 at 7:41 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 25, 2017, at 1:06 PM, Charles Srstka via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jan 25, 2017, at 2:05 PM, Ted Kremenek via swift-evolution < >

Re: [swift-evolution] warnings for out of scope?

On Wed, Jan 25, 2017 at 4:34 PM, Robert Widmann wrote: > Responding on the pro side, but I don't endorse this proposal without more > details: > > ~Robert Widmann > > 2017/01/25 13:40、Xiaodi Wu のメッセージ: > > This is contrary to several deliberate

Re: [swift-evolution] Strings in Swift 4

> On 25 Jan 2017, Dave Abrahams wrote: > >> on Tue Jan 24 2017, Ben Rimmington wrote: >> >> Could you include the latest ICU alongside the Swift standard library? > > To what end? When iOS 10 and macOS 10.12 were released (2016-09-13), their "libicucore" was based on ICU 57 (2016-03-23), with

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 1:10 PM, Dave Abrahams via swift-evolution > wrote: > >> I also prefer #1. It’s a shame that this conflicts with the potential >> syntax for variadic generics. Is there really no way around this? >> I’m showing my ignorance on compilers here,

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

> On Jan 25, 2017, at 1:06 PM, Charles Srstka via swift-evolution > wrote: > >> On Jan 25, 2017, at 2:05 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> I’d like to understand more the subjective

Re: [swift-evolution] Default Generic Arguments

Srdan, I'm afraid I don't understand your discussion. Can you simplify it for me by explaining your proposed solution in terms of Alexis's examples below? ``` // Example 1: user supplied default is IntegerLiteralConvertible func

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

I still much prefer 'testDependencies/Targets'. You seem to be confusing this proposal with the (already accepted) Package Manager Product Definitions proposal. This proposal is strictly

Re: [swift-evolution] Strings in Swift 4

Woah, not to take this totally down a different path, but I thought ContiguousArray was being deprecated? On Wed, Jan 25, 2017 at 18:48 Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Jan 25, 2017, at 04:54 PM, Ben Cohen wrote: > > I’m normally all in favor of

Re: [swift-evolution] Strings in Swift 4

On Wed, Jan 25, 2017, at 04:54 PM, Ben Cohen wrote: > I’m normally all in favor of the “don’t give people features, or they'll > use them too much” argument but in this case I don’t think it applies. That's not what I'm calling for at all. In fact, ContiguousArray and co. are a great example of

Re: [swift-evolution] Annotation of Warnings/Errors

+1, provided these differences are ignored if the user manually builds a project. Hopefully this takes some of the load off of SourceKitService. On Wed, Jan 25, 2017 at 16:07 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Yes. It would stick once it appears (until it is

Re: [swift-evolution] Annotation of Warnings/Errors

Yes. It would stick once it appears (until it is fixed, of course) > On Jan 25, 2017, at 4:02 PM, Xiaodi Wu wrote: > > I didn't read the proposal to mean vanish; rather, just lazily displayed > until some condition, but then permanently there once it shows up. It really

Re: [swift-evolution] Annotation of Warnings/Errors

I didn't read the proposal to mean vanish; rather, just lazily displayed until some condition, but then permanently there once it shows up. It really is annoying to be constantly reminded you haven't used a variable when you've literally just declared it. Once you've left the scope once, it's fair

Re: [swift-evolution] Annotation of Warnings/Errors

> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution > wrote: > > One of the biggest issues that I saw while teaching Swift to newbies (most > had not programmed before) is confusion based on the early warnings/errors > that swift/xcode gives you as they

Re: [swift-evolution] Annotation of Warnings/Errors

I'd quibble with you on the detailed design, but personally I think the general idea is quite wonderful. Quibble: I don't particularly think different-scope and different-function are in practice usefully distinct. And I think that for maximum elegance we could parallel the supported access

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

> > I’d like to understand more the subjective comments on this thread, such as > "may intimidate newcomers”. This feels very subjective, and while I am not > disagreeing with that statement I don’t fully understand its justification. > Signing up for mailing lists is fairly straightforward,

[swift-evolution] Annotation of Warnings/Errors

One of the biggest issues that I saw while teaching Swift to newbies (most had not programmed before) is confusion based on the early warnings/errors that swift/xcode gives you as they type. What would happen is that they would type a variable, and it would say… “You haven’t used this

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

> On Jan 25, 2017, at 1:05 PM, Ted Kremenek via swift-evolution > wrote: > > I have no problem with the project moving to forums instead of the Mailman > mailing lists we have now — if it is the right set of tradeoffs. I like and prefer the status quo,

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

As described in e.g. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md#what-does-abi-stability-enable , it primarily enables OSes to ship with a copy of the standard

Re: [swift-evolution] warnings for out of scope?

> On Jan 25, 2017, at 14:34, Robert Widmann via swift-evolution > wrote: > > Responding on the pro side, but I don't endorse this proposal without more > details: > > ~Robert Widmann > > 2017/01/25 13:40、Xiaodi Wu >

Re: [swift-evolution] warnings for out of scope?

Responding on the pro side, but I don't endorse this proposal without more details: ~Robert Widmann 2017/01/25 13:40、Xiaodi Wu のメッセージ: > This is contrary to several deliberate design decisions, if I understand > correctly. > > First, revisions to visibility rules in the

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 1:39 PM, Zach Waldowski wrote: > > The ultimate model of strings is going to be complicated whether or not it’s > on String itself, although I argue that regardless of that complexity, Swift > inherently starts from a much better place than f.ex. Java

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

I'm also late to the thread (and the ABI stability discussion in general). Is there a reference online that describes the reason for desiring ABI stability? I mean, I get, generally, why we need it. But I'd like to see the arguments for why we need it *now*, before certain other things are in

Re: [swift-evolution] Strings in Swift 4

The ultimate model of strings is going to be complicated whether or not it’s on String itself, although I argue that regardless of that complexity, Swift inherently starts from a much better place than f.ex. Java from just having Array vs. 30 different Array-like things. That dovetails into the

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

> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution > wrote: > > I have no problem with the project moving to forums instead of the Mailman > mailing lists we have now — if it is the right set of tradeoffs. > > My preference is to approach the topic

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Zach Waldowski wrote: > 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

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Karl Wagner wrote: >> >>> I hope I am correct about the no-copy thing, and I would also like to >>> permit promoting C strings to Swift strings without validation. This >>> is obviously unsafe in general, but I know my strings... and I care >>>

[swift-evolution] Swift ABI Stability Manifesto

I put together a document compiling many conversations with many people about Swift’s ABI and what needs to happen prior to ABI stability. It is meant to be a blueprint for the project on how to approach and achieve ABI stability, as well as a resource to the community. It can be viewed fully

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 8:16 PM, Zach Waldowski via swift-evolution > wrote: > > I strongly want Swift to have world-class string processing, but I believe > even more strongly in the language's spirit of progressive disclosure. > Newcomers to Swift's current String

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 10:03, Xiaodi Wu via swift-evolution > wrote: > > Stephen Canon wrote that Arithmetic should refine ExpressibleByIntegerLiteral > because of certain mathematical properties of rings. In that case, 0 and 1 > would just be spelled in that way.

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Matt Whiteside wrote: >> 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

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 7:02 PM, Félix Cloutier via swift-evolution > wrote: > > >> 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 >

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

> On Jan 25, 2017, at 2:05 PM, Ted Kremenek via swift-evolution > wrote: > > I’d like to understand more the subjective comments on this thread, such as > "may intimidate newcomers”. This feels very subjective, and while I am not > disagreeing with that statement I

Re: [swift-evolution] Optional Assignment Operator

Given lack of evidence of harm, is it really important to make such a source-breaking change? On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch > wrote: > > Agreed, IMO it

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 12:23 PM, Joe Groff via swift-evolution > wrote: > > >> On Jan 24, 2017, at 9:35 PM, Chris Lattner via swift-evolution >> > wrote: >> >> On Jan 24, 2017, at 12:05 AM, Chris Eidhof

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

I have no problem with the project moving to forums instead of the Mailman mailing lists we have now — if it is the right set of tradeoffs. My preference is to approach the topic objectively, working from goals and seeing how the mailing lists are aligning with those goals and how an

Re: [swift-evolution] Default Generic Arguments

That's a good example Alexis. I do agree that generic arguments are inferred in a lot of cases, my point was that they should not be inferred in "type declarations". Not sure what's the right terminology here, but I mean following places: (I) Variable/Constant declaration ``` let x: X ```

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch wrote: > If no uses are found (which I suspect will be the case), it becomes hard to > also find evidence of harm other than in contrived scenarios. Perhaps > contrived will be all we can find. Well, if there's no harm,

Re: [swift-evolution] Optional Assignment Operator

If no uses are found (which I suspect will be the case), it becomes hard to also find evidence of harm other than in contrived scenarios. Perhaps contrived will be all we can find. Anyway, this is a bit off-topic for this thread... On Wed, Jan 25, 2017 at 11:24 AM John McCall

Re: [swift-evolution] protocol-oriented integers (take 2)

I wish I knew how to express those requirements in the type system. This is a good way to implement additiveIdentity but I assume that Arithmetic protocol implies behavior of Addable. > On Jan 25, 2017, at 20:58, David Sweeris wrote: > >> >> On Jan 25, 2017, at 07:59,

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 1:58 PM, David Sweeris via swift-evolution > wrote: > > >> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution >> wrote: >> >> Hi everyone, >> >> I want to suggest a tiny extension to an Arithmetic

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 24 2017, Ben Rimmington wrote: > > >> 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

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu wrote: > Given lack of evidence of harm, is it really important to make such a > source-breaking change? My first instinct is that, no, it's not important. However, we haven't actually *tried* to find any evidence of harm, so it's

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my iPhone > On Jan 25, 2017, at 1:45 PM, David Sweeris via swift-evolution > wrote: > > >> On Jan 25, 2017, at 10:03, Xiaodi Wu via swift-evolution >> wrote: >> >> Stephen Canon wrote that Arithmetic should refine >>

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 25, 2017, at 07:59, Anton Mironov via swift-evolution > wrote: > > Hi everyone, > > I want to suggest a tiny extension to an Arithmetic protocol. It would be > nice to have an additive identity and a multiplicative identity constants. > Basically zero and

Re: [swift-evolution] Strings in Swift 4

One concern I have with implementing this through pattern matching is that it might make it really hard to optimize. For example, consider the following hypothetical fragment: switch string { case "x" (let remainder): return arc4random() % 2 == 0 ? parse1() : parse2() This would

Re: [swift-evolution] protocol-oriented integers (take 2)

It should already be possible to handle special cases like that since you can reässign self in an initializer. Here's a contrived example; would it allay your performance concerns? ``` struct Foo: ExpressibleByIntegerLiteral { private let value: String private static let zero = Foo("a

Re: [swift-evolution] Default Generic Arguments

Yes, I agree with Xiaodi here. I don’t think this particular example is particularly compelling. Especially because it’s not following the full evolution of the APIs and usage, which is critical for understanding how defaults should work. Let's look at the evolution of an API and its

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

Would using arbitrary label names in statements like `case .foo ( let bar )` still work? See my example below? There is some code that does this, but it can be fixed with a simple string replacement for nearly all cases, I would think. > On Jan 24, 2017, at 8:10 PM, Xiaodi Wu via

Re: [swift-evolution] Optional Assignment Operator

-1 I personally think Optional has received too much special treatment in the language already. I’ve known folks who have written Swift professionally for almost a year until they realize Optional is just an enum. More magic syntax around it would only make this worse. > On Jan 25, 2017, at

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch wrote: > > Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other > than "a = a ?? b". > > On another note, I don't see the value of "a? = b". I had never realized > before that this works. Is this

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

Hi Derrick, I think you meant to send this as a reply to SE-0149 Package Manager Support for branches, correct? I’m not quite sure about the use case for your described behaviour, can you elaborate a bit more why you would want to override a dependency of A from the manifest of P? If the

Re: [swift-evolution] Optional Assignment Operator

Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything other than "a = a ?? b". On another note, I don't see the value of "a? = b". I had never realized before that this works. Is this feature actually used in the wild? Should we consider removing it? (I could perhaps see some

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

Hi David, My apologies for being late to the thread — I've been away for the last week. ABI stability remains a keystone goal for Swift, but the concerns you have here about not rushing important things are real. There's been a lot of scoping work into what ABI stability means, soup-to-nuts

Re: [swift-evolution] warnings for out of scope?

This is contrary to several deliberate design decisions, if I understand correctly. First, revisions to visibility rules in the Swift 3 timeline were made with the deliberate intention that it should be possible to model greater visibility within a type (e.g. public members) without actually

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution > wrote: > Really? My observation from a quick test is that "a? = b" assigns b to a if a > already has a value, or does nothing if it's nil. This is sort of the > opposite of what's being

Re: [swift-evolution] warnings for out of scope?

So, to be clear, a warning about making internal variables more private based on their usage in the entire module? Sounds doable. Probably wouldn't need to go through evolution to get it too (but I'll let others make that call). Please file an SR about this too. ~Robert Widmann 2017/01/25

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 9:35 PM, Chris Lattner via swift-evolution > wrote: > > On Jan 24, 2017, at 12:05 AM, Chris Eidhof via swift-evolution > > wrote: >> >> I agree that being able to implement parsers

Re: [swift-evolution] Optional Assignment Operator

Interesting, I think I misread it too. The one I was thinking of is the same as the rejected proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md Jacob On Wed, Jan 25, 2017 at 10:11 AM, Joe Groff wrote: > > > On Jan 25, 2017,

Re: [swift-evolution] Optional Assignment Operator

-1 On Wed, Jan 25, 2017 at 1:11 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch > wrote: > > > > Really? My observation from a quick test is that "a? = b" assigns b to a > if a already has a value,

Re: [swift-evolution] protocol-oriented integers (take 2)

Stephen Canon wrote that Arithmetic should refine ExpressibleByIntegerLiteral because of certain mathematical properties of rings. In that case, 0 and 1 would just be spelled in that way. Otherwise, +1. On Wed, Jan 25, 2017 at 11:38 Anton Mironov via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 9:47 AM, Jacob Bandes-Storch wrote: > > Really? My observation from a quick test is that "a? = b" assigns b to a if a > already has a value, or does nothing if it's nil. This is sort of the > opposite of what's being proposed, which is that "a ?= b"

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

Hi Martin, > On 25 Jan 2017, at 10:40, Martin Waitz via swift-evolution > wrote: > > Hello, > > Am 2017-01-24 19:18, schrieb Daniel Dunbar via swift-evolution: >> The review of SE-0150 “ Package Manager Support for branches" begins >> now and runs through January

[swift-evolution] warnings for out of scope?

Hi! I’m somewhat new to swift, so this issue may have been covered. I really like how I get a warning for variables I’ve declared, but have not mutated, or constants that I did not read. What about warnings for anything not accessed outside its declared scope, encouraging the use of private,

Re: [swift-evolution] Strings in Swift 4

On Jan 24, 2017, at 12: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. +1 from me as well, I agree with Joe that Swift can learn a

Re: [swift-evolution] Reduce with inout

Should combine be allowed to throw, thus forcing this method to rethrow? Begin Message Group: gmane.comp.lang.swift.evolution MsgID:

Re: [swift-evolution] Optional Assignment Operator

> On Jan 25, 2017, at 8:40 AM, Nichi Shin via swift-evolution > wrote: > > I’d like to propose a new operator for optional assignment in Swift. > > The idea is that by using this operator (e.g. by doing a ?= b), the optional > on the right would be assigned to the

[swift-evolution] Optional Assignment Operator

I’d like to propose a new operator for optional assignment in Swift. The idea is that by using this operator (e.g. by doing a ?= b), the optional on the right would be assigned to the variable on the left only when it has something to assign (i.e. when it's not nil). The implementation could

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

This is both great to hear (ivar introspection available) and a little disappointing (method level not). Basically, I would hope for at least enough to allow implementation of KVC - which would require the ability to find and invoke methods by name. > On Jan 24, 2017, at 14:16, Joe Groff

Re: [swift-evolution] Optional Assignment Operator

I think this is the same proposal as this rejected proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md > Le 25 janv. 2017 à 08:56, Sean Heber via

Re: [swift-evolution] Strings in Swift 4

Great stuff! I wonder if built-in grammars (that's what Perl calls them) would work only for things that are backed by string literals, or if it's worth the time/effort to make them work for other kind of data as well. For example, what if you write a grammar to tokenize (yielding some sequence

[swift-evolution] Reduce with inout

Apologies if this reply comes across the list multiple times... Should combine be allowed to throw, thus forcing this method to rethrow? > Begin Message > Group: gmane.comp.lang.swift.evolution > MsgID:

Re: [swift-evolution] Reduce with inout

I like it too! Thanks Pyry! Will change the proposal. On Wed, Jan 25, 2017 at 8:09 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Yep, that's really good. > > On 25 Jan 2017, at 08:00, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > +1 Best

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

> On 25-Jan-2017, at 4:02 AM, Robert Widmann via swift-evolution > wrote: > > Hello Swift Community, > > Harlan Haskins and I have been working on libraries > to make interacting with LLVM and Clang’s > APIs more elegant with native