Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

On Wed, Jan 10, 2018 at 3:06 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I continue to have concerns about this proposal, and I'm gravely and very > bitterly di

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

Re-reading this thread and thinking about it more, I think I agree :) Updating again... On Sat, Dec 30, 2017 at 3:44 PM, Chris Lattner wrote: > On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Sorry for the delay.

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

ain? I would like to help with the proposal and > even attempt implementation. > > I also need to catch up on the resilient discussion regarding enum case > ordering. > > On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> w

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

Jacob Bandes-Storch On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon wrote: > On Nov 14, 2017, at 5:21 PM, Xiaodi Wu wrote: > > 1. It must be possible to easily access the count of values, and to access >> any particular value using contiguous `Int` indices. This could be achieved >> either

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

Over a year ago, we discussed adding a magic "allValues"/"allCases" static property on enums with a compiler-derived implementation. The original proposal PR has been reopened for Swift 5 after languishing for a while, and I'd like to revisit it a

Re: [swift-evolution] [Pitch] Guard/Catch

Some prior, probably not as well thought-through, discussion on this topic: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011446.html On Wed, Jul 5, 2017 at 10:40 AM Soroush Khanlou via swift-evolution < swift-evolution@swift.org> wrote: > I’d like to propose a guard/catch

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

I've found a similar thing useful, but with Errors instead of fatalErroring: infix operator ?! : NilCoalescingPrecedence func ?!(lhs: T?, rhs: @autoclosure () -> Error) throws -> T { if let lhs = lhs { return lhs } throw rhs() } let x = try failableFunc() ?! MyError.somethingFailed On

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

Awesome! :) 3.1.1 is a great start — any plans to include recent nightly builds of the compiler, similar to IBM's Swift Sandbox ? On Thu, Jun 22, 2017 at 10:24 AM, Adam Nemecek via swift-evolution < swift-evolution@swift.org> wrote: > Howdy, > Matt Godbolt and

Re: [swift-evolution] Swift phases and mis-timed proposals

On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > I support everything Jon wrote. > > +1 Free-for-all brainstorming venue separate from focused proposal > discussion. > +1, particularly for this being a section in Discourse ;-) __

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Now that escaping with \ has been proposed for KeyPaths, this makes me wonder whether it would be appropriate to use "\foo()" rather than "foo(_)"/"foo(:)" ? It still feels a bit strange, as \foo() looks like escaping the *result* of a call. On Sat, Feb 25, 2017 at 1:43 PM, David Hart wrote: >

Re: [swift-evolution] 'Random' Improvements

Directly copying a swift-evolution email I sent almost exactly a year ago: I encourage anyone thinking about PRNG APIs to check out what C++ STL has > to offer: http://en.cppreference.com/w/cpp/numeric/random > And this analysis/extension of it: http://www.pcg-random.org/ > posts/ease-of-use-witho

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

On Sat, Mar 11, 2017 at 5:34 AM, Brent Royal-Gordon wrote: > > On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch > wrote: > > > > I'm confused by this example — was > > ExpressibleByFailableStringInterpolation's > init() supposed to be failable here? > > Ugh, yes, I'm sorry. That should have be

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

On Fri, Mar 10, 2017 at 4:44 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Mar 10, 2017, at 8:49 AM, Joe Groff wrote: > > > > I think there's a more powerful alternative design you should also > consider. If the protocol looked like this: > > > > protocol E

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

This is clean, but given knowledge of foo(bar:) syntax, its discoverability is low. Conversely, given knowledge of `foo()`, the discoverability of foo(bar:) would be low compared to `foo(bar:)`. If backticks were the *only* option, and also worked as `foo(bar:)`, the consistency would be appealing

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Just to throw out some other options: foo(#) and foo(@). (And you thought we'd gotten rid of # argument labels! 😉) On Wed, Feb 22, 2017 at 11:48 AM David Sweeris wrote: > > > On Feb 22, 2017, at 11:05 AM, Matthew Johnson > wrote: > > > > > >> On Feb 22, 2017, at 12:30 PM, David Sweeris > wrot

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

There were some opinions on Slack that we should simply change `foo` so that it can *only* refer to the nullary version. That'd be a source-breaking change, but I'm also not sure whether it's even solve the problem — is it true you might still have both a function and a variable named foo accessib

Re: [swift-evolution] [Discussion] Allowing extending existentials

This works today: protocol P1{} protocol P2{} extension P1 where Self: P2 { func foo() {} } func bar(x: P1 & P2) { x.foo() } On Tue, Feb 21, 2017 at 10:53 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Hello list, > > Found out yesterday that you can’t extend

[swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Evolutioniers, *Compound name syntax* — foo(_:), foo(bar:), foo(bar:baz:) — is used to disambiguate references to functions. (You might've used it inside a #selector expression.) But there's currently no compound name for a function with no arguments. func foo() {} // no compound syntax for

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

On Sat, Feb 18, 2017 at 8:49 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > I'm on vacation and don't have time for a full review right now, but I am > concerned that wild this proposal would make enums more general and uniform > with the rest of the language , they al

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

On Tue, Feb 7, 2017 at 1:15 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > Believe it or not, not everyone in the world can afford the device and > data plan for a JavaScript-rich web front end (I'm aware of the mobile > apps). I remember only being able to buy an iPod Tou

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

Gmail does the same; I wonder if it's a Mailman feature/bug that triggers the splitting. On Mon, Feb 6, 2017 at 7:59 PM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > Oh, Mail messes up the grouping of them quite a lot in my experience. > Whenever we get one of those epic

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

On Thu, Feb 2, 2017 at 6:37 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Feb 2, 2017 at 8:03 PM, Ted kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Feb 2, 2017, at 5:35 PM, Karl Wagner via swift-evolution < >> swift-evolution@swi

Re: [swift-evolution] for-else syntax

One possible con: this is subtly but extremely different from Python, where a for loop's else clause is executed only if there was no `break` from the loop. On Wed, Feb 1, 2017 at 8:48 AM Chris Davis via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > Often when I’m programming I stu

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

Cute. Reminds me of C++ STL's struct tags: http://en.cppreference. com/w/cpp/utility/piecewise_construct_t http://en.cppreference.com/w/cpp/iterator/iterator_tags On Tue, Jan 31, 2017 at 12:53 PM, Max Moiseev via swift-evolution < swift-evolution@swift.org> wrote: > Hi Brent, > > Thanks a lot for

Re: [swift-evolution] Removing enumerated?

I'm still a fan of that indexed() proposal... On Tue, Jan 31, 2017 at 8:52 AM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 31, 2017, at 10:46 AM, Chris Eidhof wrote: > > I agree that it's very useful. I use it regularly. The documentation isn't > that unclear,

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

You said "The ability to reference a function by only the first segment of its name is likewise legacy of the original model..." — how else could you refer to a nullary function? Even if labels were required for naming (>0)-ary functions, there's still ambiguity between a nullary function and a var

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

Although there's no spelling for this... https://bugs.swift.org/browse/SR-3550 On Mon, Jan 30, 2017 at 7:29 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 30, 2017, at 11:42 AM, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote: > > > > The re

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

Plus (heart), but not minus. Although it looks like someone has written a plugin for this: https://meta.discourse.org/t/retort-a-reaction-style-plugin-for-discourse/35903 On Mon, Jan 30, 2017 at 5:35 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > Does Discourse allow stu

Re: [swift-evolution] Why doesn't Swift allow a variable and a function with the same name?

Suppose it were allowed. What should this do? let something = randomArray On Mon, Jan 30, 2017 at 11:37 AM, Michael Gubik via swift-evolution < swift-evolution@swift.org> wrote: > Example that does not compile: > > let randomArray = randomArray(withCapacity: 4096) > > Compiler er

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

UX: *---EmailJIRADiscourse> 😉 On Thu, Jan 26, 2017 at 5:10 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > I'm surprised there is so little support for JIRA. Anyone think it's a bad > tool for the job? > On Thu, Jan 26, 2017 at 6:38 PM Nevin

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

On Thu, Jan 26, 2017 at 12:43 PM, James Berry via swift-evolution < swift-evolution@swift.org> wrote: > > Since many will likely want to continue to access the discussion via mail, > I have some questions for anybody who actually has real-life experience in > using Discourse primarily via email: >

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

I took some screenshots of this: http://discourse.natecook.com/t/pitch-replace-discourse-with-a-mailing-list/3052/3 We can do some further testing once we set up inbound email support. On Thu, Jan 26, 2017 at 11:58 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Awesome!

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

Not true if you quote something via the web interface. See my quote here: http://discourse.natecook.com/t/pitch-add-dark-mode-to-swift/3051 On Thu, Jan 26, 2017 at 12:03 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jan 26 2017, Nate Cook wrote: > > > ✋ > >

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 1

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 < > swift-evolution@swift.org> wrote: > >

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] [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 list is a *commitment.*

Re: [swift-evolution] Optional Assignment Operator

so comes up with optional properties, I think, which is something we > weren't always certain we were going to ban in native Swift (as opposed to > imported ObjC code, where they're a fact of life). > > John. > > > Jacob > > On Wed, Jan 25, 2017 at 10:28 AM, Jo

Re: [swift-evolution] Optional Assignment Operator

oving it? (I could perhaps see some value if the assignment operator were overloadable, but it's not.) Jacob On Wed, Jan 25, 2017 at 10:28 AM, John McCall wrote: > On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > R

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, at 9:47 AM, Jacob B

Re: [swift-evolution] Optional Assignment Operator

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" should assign to a only if it does NOT have a value. On Wed, Jan 25, 2017 at 9:33 AM Joe Grof

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

Obligatory prior discussion sheds, er, I mean threads: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025692.html / https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160801/thre

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

On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > One example: earlier, it was demonstrated that a genetic lerp would not > accommodate vector types. However, it _does_ work fine for any scalar (i.e. > field) type; however, with the currently prop

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

On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > >> [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f >> 3fcc7cad8c ] >> >

Re: [swift-evolution] Pattern matching with Arrays

On Tue, Jan 3, 2017 at 10:10 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 22, 2016, at 7:43 PM, Robert Widmann > wrote: > > Do you think there’s room for a more general Pattern Synonyms-like > feature that

Re: [swift-evolution] Generic Subscripts

On Sat, Jan 14, 2017 at 3:41 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jan 13 2017, John McCall wrote: > > > I'm also not sure we'd ever want the element type to be inferred from > > context like this. Generic subscripts as I see it are about being > >

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

[ proposal link: https://gist.github.com/moiseev/ 62ffe3c91b66866fdebf6f3fcc7cad8c ] On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Responding to both Jacob and Xiaodi here; thanks very much for your > feedback! > > on Sat Jan 14 2017,

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

Great work, all. I'm not sure I ever commented on SE-0104, so I've read through this one more carefully. Here are some things that came to mind: *## Arithmetic* Why are ExpressibleByIntegerLiteral and init?(exactly:) required? I could understand needing access to 0, but this could be provided by

Re: [swift-evolution] [swift-users] Implementing signum

On Sat, Nov 19, 2016 at 11:59 PM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > From some older evolution-thread: > > extension SignedNumberType { > var sign: Self { >if self == (0 as Self) { > return (0 as Self) >} else if self > (0 as Self

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

On Wed, Oct 19, 2016 at 10:12 AM, Alex Martini wrote: > Grammar changes > > operator → operator-head operator-characters[opt] > > operator-head → ! % & * + - / < = > ? ^ | ~ > operator-head → operator-dot operator-dots > operator-character → operator-head > operator-characters → operator-characte

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

Dear Swift-Evolution community, A few of us have been preparing a proposal to refine the definitions of identifiers & operators. This includes some changes to the permitted Unicode characters. The latest (perhaps final?) draft is available here: https://github.com/jtbandes/swift-evolution/blob/

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

Proposal link: https://github.com/apple/swift-evolution/blob/master/propo sals/0144-allow-single-dollar-sign-as-valid-identifier.md > * What is your evaluation of the proposal? > -1. The proposal does not actually provide motivation for keeping $ beyond "the Dollar library alre

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

+1. Haven't hit this issue personally, but I agree it's important and the proposed solution seems like the right fix. On Tue, Oct 11, 2016 at 2:28 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > Introduction > > This proposal addresses significant unexpected performance ga

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

On Sat, Oct 8, 2016 at 4:00 AM, Karl via swift-evolution < swift-evolution@swift.org> wrote: > It’s one of those issues where everybody agrees we could do better but > nobody cares enough to do anything about it. > No, I think if you read this thread (and the others) I think you'll find that not

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Wed, Sep 28, 2016 at 1:46 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote: > That's a bunch of complexity for no benefit. Why would you ever use this > as a collection? I think getting an element and an index simultaneously from, for instance, collection.indexed().sor

Re: [swift-evolution] Lexical matters: identifiers and operators

Hi Jonathan, I started another discussion on this a couple weeks ago. I haven't had time to make any progress on the topic lately, but I'm hoping to do so this weekend. Glad to hear you're interested! https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160912/027108.html Jacob On Sa

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

This point seems moot to me because String's == checks for *canonical equivalence* anyway. On Thu, Sep 22, 2016 at 4:54 PM Michael Gottesman via swift-evolution < swift-evolution@swift.org> wrote: > On Sep 22, 2016, at 4:19 PM, Xiaodi Wu wrote: > > You mean values of type String? > > > I was spea

Re: [swift-evolution] Unicode identifiers & operators

Side question: it looks like ICU is used by the standard library on non-Apple platforms. Would it be possible to make it a dependency of the compiler too? If we want to explicitly detect emoji, for instance, it'd be nice to use a canonical library that already does it. On Sun, Sep 18, 2016 at 12:3

Re: [swift-evolution] Unicode identifiers & operators

On Sun, Sep 18, 2016 at 6:34 PM, Robert Widmann wrote: > Some thoughts > > On Sep 18, 2016, at 3:33 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > *TL;DR:* > > Swift 4 Stage 1 seeks to prioritize "Source stability featur

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

Hi João, I think you should definitely put up a PR for this. I'm restarting the discussion about allowed operator/identifier characters ( https://gist.github.com/jtbandes/c0b0c072181dcd22c3147802025d0b59), and I think your proposal is an obvious requirement for any solution to be complete. :-) Jac

[swift-evolution] Unicode identifiers & operators

*TL;DR:* Swift 4 Stage 1 seeks to prioritize "Source stability features". Most source-breaking changes were done with in Swift 3; however, the categorization of Unicode characters into identifiers & operators was never thoroughly discussed on swift-evolution. This seems like it might be our last c

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu wrote: > On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch > wrote: > >> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: >> >>> This suggestion has been pitched earlier and I've expressed my opinion >>> in those earlier threads, but I'll repeat mys

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

I've filed https://bugs.swift.org/browse/SR-2582 for this. On Tue, Sep 6, 2016 at 10:37 AM, Jordan Rose wrote: > > On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev < > swift-...@swift.org> wrote: > > > On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch > wrote: > > Here are a few thoughts:

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: > This suggestion has been pitched earlier and I've expressed my opinion in > those earlier threads, but I'll repeat myself here: > > I'm hugely opposed to such changes to the precedence table. Those of us > who work with bitwise operators on a reg

Re: [swift-evolution] [Meta] Proposal status page

It'd be great to see swift.org as just another repo on github.com/apple via GitHub Pages ;-) Jacob On Tue, Sep 6, 2016 at 8:45 PM, Jordan Rose wrote: > > > On Sep 6, 2016, at 05:47, Ben Rimmington via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > >> On 6 Sep 2016, at 07:11

Re: [swift-evolution] [Meta] Proposal status page

Is it possible to have a repo named apple.github.io, and still allow individual repos having their own pages (like apple.github.io/swift-evolution)? Jacob On Mon, Sep 5, 2016 at 7:05 AM, Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > > > On 21 Jul 2016, at 19:10, Jordan

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> > https://github.com/apple/swift-evolution/blob/master/ > proposals/0140-bridge-optional-to-nsnull.md > > >- What is your evaluation of the proposal? > > I tend to agree with other commenters that NSNull does not seem like an obviously-correct (or -unsurprising) solution to this problem. Rath

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

Perhaps-conversely, what should this code do? let nextIndex = foundIndex ?? lastIndex + 1 Jacob On Sat, Sep 3, 2016 at 9:05 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Given: `let x = Optional(3)` then > > `let y = 5 + x ?? 2` will not compile > > but > > `let

Re: [swift-evolution] New feature request: syntactic sugar for "if let" scoped self assignment

For context, some prior discussions on this topic: "Reconsidering SE-0003 Removing var from Function Parameters and Pattern Matching" (couldn't find one representative message — search it yourself https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/thread.html ) The bind thread

Re: [swift-evolution] InternalString class for easy String manipulation

Here's a little prior discussion about ASCIIString: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002138.html Jacob On Sun, Aug 14, 2016 at 3:41 PM, Michael Savich via swift-evolution < swift-evolution@swift.org> wrote: > Back in Swift 1.0, subscripting a String was easy

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

Hi Dave, I just filed https://bugs.swift.org/browse/SR-2303. Brainstorming: is it important that the init(stringInterpolation:) and init(stringInterpolationSegment:) requirements are on the same type? Perhaps it would work to separate these two requirements, allowing the segments to construct inte

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

If you were to design this API for Swift in the first place, you might want to do something entirely different: extension URL { enum Reachability { case reachable case notReachable(ErrorProtocol) } func reachability() -> Reachability } On Sun, Aug 7, 2016 at 12:20 PM,

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

nt Royal-Gordon via swift-dev < > swift-...@swift.org> wrote: > > > >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> • a top-of-file "shebang"-style comm

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

-time error. On Tue, Aug 2, 2016 at 6:10 PM, Brent Royal-Gordon wrote: > > On Jul 30, 2016, at 10:35 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > > > In the past, there has been some interest in refining the behavior of > Ex

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

As I mentioned at the top of this thread, Discourse provides free hosting for community-friendly open-source projects which I suspect would include Swift. If not, that would indeed throw a wrenc

Re: [swift-evolution] [Idea] Generic subscripts

+1 from me on this feature as well. It seems like a pretty obvious way in which subscripts should be like functions, but aren't yet. Would there be any need for setters and getters to have different generic parameters? I suppose today there's only one place to specify the type of the parameters, a

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I hope my replies aren't too curt — I don't want to pick a fight (any more than I did by starting this topic), but to explore how Discourse can serve these use cases. Feel free to re-rebut. On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon wrote: > > I don't think enough has been said in favor

[swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

In the past, there has been some interest in refining the behavior of ExpressibleByStringInterpolation (née StringInterpolationConvertible), for example: - Ability to *restrict the types that can be used* as interpolation segments - Ability to *distinguish the string-literal segments* from interpo

[swift-evolution] [Swift4] Mailing list vs. Forum

Branching... On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 29, 2016, at 5:14 PM, Brandon Knope wrote: > > > > Chris, has the core team discussed opening up a forum for discussing > proposal implementations. > > > > Some of us aren

Re: [swift-evolution] [Swift 4] Organizing source stability

> > On Jul 29, 2016, at 5:20 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > Chris writes: > >> - *Source stability features: *These should be relatively small, but >> important. For example, we need a “-std=swift3” sort of c

[swift-evolution] [Swift 4] Organizing source stability

Chris writes: > - *Source stability features: *These should be relatively small, but > important. For example, we need a “-std=swift3” sort of compiler flag. We > may also add a way to conditionally enable larger efforts that are under > development but not yet stable - in order to make it easie

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

I figured that sentence was in reference to the methods currently named flatten(). The proposal also said that the String-based version of joined(separator:) (which are implemented separately) should have a default separator of "". There is currently no flatten() for collections of Strings. https

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

Does the core team have feedback on whether Collection's joined(separator:) should have a default separator of "", or another overload with no parameter? On Wed, Jul 27, 2016 at 2:56 PM, Jacob Bandes-Storch wrote: > I'll get right on it. Thanks to everyone who provided great feedback > during t

Re: [swift-evolution] [Accepted] SE-0133: Rename flatten() to joined()

I'll get right on it. Thanks to everyone who provided great feedback during the review! On Wed, Jul 27, 2016 at 2:53 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-

Re: [swift-evolution] End of source-breaking changes for Swift 3

> > >- SE-0089 - Renaming String.init(_: T) > > > > Has anyone worked on this? I have some time in the next couple of days and might be able to come up with an implementation in time.

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

On Mon, Jul 25, 2016 at 2:09 PM, David Rönnqvist wrote: > > Haskell calls the general *m (m a) -> m a* function for "join", but also > has a specialized *[[a]] -> [a]* function called "concat". (The function > corresponding to "flatMap" is called "bind" in Haskell (although used as an > operator),

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > I'm giving the overall idea a +0 and the specific proposal as currently > written a -1, because I think this is a much more complicated bikeshed > than it appears to be on the surface and the

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

I wasn't explicit about that in the proposal, but I was intending that these should be renamed too. There's a minor snag: JoinedSequence already exists. I haven't taken a close look at both implementations yet, but it's possible we could just combine them. On Mon, Jul 25, 2016 at 12:46 AM, Charlie

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> > > https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md > > * What is your evaluation of the proposal? > +1 on drop{First,Last}() → removing{First,Last}(). +1 on drop{First,Last}(_:) → removing{Prefix,Suffix}(_:). +1 on drop(while:) → removingPrefix(wh

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

The latest comment from Brent on the PR indicated that it's ready, I believe. Jacob On Sun, Jul 24, 2016 at 10:39 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

we could do this too >> >> [["hey"], ["what"]].joined(separator: []).joined(separator: "") >> >> >> >> On Jul 24, 2016, at 5:29 PM, Jose Cheyo Jimenez >> wrote: >> >> -1 for this. To me there needs to

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

wrote: > > -1 for this. To me there needs to be a difference between String (which is > not a normal collection) and other regular collections. > > In addition, I really don’t think this proposal has the needed strong > support for the change. > > > > > On Jul 22, 201

Re: [swift-evolution] [Draft] Fix a typo in two String methods

+1 On Sat, Jul 23, 2016 at 1:41 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > World's shortest proposal: > > > *Introduction* > > In `String`, the methods `nulTerminatedUTF8` and > `nulTerminatedUTF8CString` have the word "null" misspelled > > *Motivation* > > There is a

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

Here's a proposal draft. Comments welcome: https://gist.github.com/jtbandes/7978dc1848f7c37eeaa8e9aba27c7325 On Fri, Jul 22, 2016 at 2:51 PM, Ben Rimmington wrote: > > > On 22 Jul 2016, at 20:43, Jacob Bandes-Storch > wrote: > > > >> On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington > wrote: >

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

On Fri, Jul 22, 2016 at 8:35 AM, Ben Rimmington wrote: > > > On 22 Jul 2016, at 02:46, Jacob Bandes-Storch wrote: > > > > In the swift-lang Slack channel, a few of us were discussing > joined(separator:) and realized that flatten() does almost exactly the same > thing. > > > > Is there interest i

[swift-evolution] [Pitch] Unify joined(separator:) and flatten()

In the swift-lang Slack channel, a few of us were discussing joined(separator:) and realized that flatten() does almost exactly the same thing. Is there interest in renaming flatten() to joined()? Since joined takes a separator that's any Sequence, we can't have a default value for the separator

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Great! I have an attempted implementation here. Would appreciate if someone can kick off a CI build/test. https://github.com/apple/swift/pull/3637 On Wed, Jul 20, 2016 at 5:38 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swi

Re: [swift-evolution] Change Request: Make myString.hasPrefix("") and myString.hasSuffix("") return true

Not that it's needed, but another +1 from me. a.hasPrefix(p) should be true iff there exists some string x for which p+x == a. If p == "", then x := a satisfies this, so hasPrefix should return true. Jacob On Tue, Jul 19, 2016 at 1:29 PM, Jaden Geller via swift-evolution < swift-evolution@swift

Re: [swift-evolution] [Meta] Proposal status page

Jul 18, 2016 at 4:57 PM, Mark Lacey wrote: > > On Jul 18, 2016, at 4:44 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > This is now live: http://apple.github.io/swift-evolution/ > > > Very very nice! > > I won

  1   2   3   >