Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Something like `#unknown` or `#undiscovered` in the pattern matching syntax makes complete sense. -Richard > On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution > wrote: > > The mega-thread about SE-0192 is a bit large, and I’d like to talk about one > specific point. In the review

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 29, 2017, at 07:25, Chris Lattner via swift-evolution > wrote: > > >> On Nov 29, 2017, at 12:46 AM, Brent Royal-Gordon >> wrote: >> >>> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: >>> >>> We’ve had a lot of discussions over the years about how to balance >>> simplicity vs

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Nov 1, 2017, at 21:13, Chris Lattner via swift-evolution > wrote: > >> On Nov 1, 2017, at 3:20 AM, Richard Wei > > wrote: Since you bring it up, Python exceptions will be annoying - As with other languages, Python can throw from an arbitrary expre

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Nov 1, 2017, at 03:14, Richard Wei via swift-evolution > wrote: > > > >> On Oct 31, 2017, at 21:31, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Also, for sake of discussion, we’d have to figure ou

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Oct 31, 2017, at 21:31, Chris Lattner via swift-evolution > wrote: > > Also, for sake of discussion, we’d have to figure out what the type of > MemberLookupResultType would be for Python. I can see several choices: > > 1) Make it return a "PythonObject!” > 2) Make it strict, returning

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

+1. -Richard > On May 18, 2017, at 01:48, Anders Kierulf via swift-evolution > wrote: > > I want to bring this up one last time in swift-evolution to give this issue a > chance to not fall through the cracks. Passing a value to UnsafeRawPointer > should not force that method to be mutating.

Re: [swift-evolution] [Review] SE-0179: Swift `run` Command

> What is your evaluation of the proposal? Excellent, except that `--chdir` and `--in-dir` are confusing. Why not use a long, clear name, just like `—enable-prefetching`? Consider `—working-dir` & `—preexec-working-dir`. > Is the problem being addressed significant enough to warrant a change to

Re: [swift-evolution] [Pitch] Swift needs fixed-size array

Huge +1. We definitely need fixed-size arrays. Just in addition to elegantly importing C arrays, this will enable static matrix/tensor shapes for shape-safe compute operations like GEMM. Moreover I think we can learn from Rust about their recent discussion on constant generics. -Richard > On A

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

+1. We better make sure `equalTo:` is consistent with the label in the `Sequence.all` proposal. -Richard > On Apr 8, 2017, at 19:41, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>

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

`withoutException` sounds confusing to me. And it’ll potentially make a Swift newcomer think it has something to do with runtime exceptions. IMO `forAll(_:)` is the best name. It looks logically, quantificationally clear. With regard to the possible confusion w/ `forEach`, the “each" in `forEac

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

I agree. But I don’t think the predicate needs an argument label. `membersSatisfy(_:)` or `forAll(_:)` sounds better. -Richard > On Mar 31, 2017, at 23:02, Will Stanton via swift-evolution > wrote: > > +1 to adding, but the name `all` suggests (to me) the return of another > sequence, not a

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

In addition, I think # and @ are very confusing since they are not one of the existing symbols in function name syntax. -Richard > On Feb 22, 2017, at 15:25, Richard Wei wrote: > > I prefer the `foo(_)` option and keeping the one-colon-per-arg rule. > > Intuition: > Underscore means no label.

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

I prefer the `foo(_)` option and keeping the one-colon-per-arg rule. Intuition: Underscore means no label. Colon means one argument. foo(_:) – one arg with no label foo(_) – no arg with no label -Richard > On Feb 22, 2017, at 14:27, Jacob Bandes-Storch via swift-evolution > wrote: > > Just to

[swift-evolution] [Pitch] #if swift version with third version component

Hi, Foundation in 3.0-RELEASE didn't fully resolve the renaming in SE-0086, so we have `RegularExpression` on Linux and `NSRegularExpression` on macOS. The naming is now unified in Swift 3.0.1, but there doesn’t seem to be a possible way to resolve the code breaking change. Consider the example

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

+1. Since we can do `let a, b, c, ...`, it makes sense for `import` to support comma-separated lists. -Richard > On Oct 15, 2016, at 20:24, Erica Sadun via swift-evolution > wrote: > > >> On Oct 15, 2016, at 6:41 PM, Charles Constant via swift-evolution >> mailto:swift-evolution@swift.org>>

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

> * What is your evaluation of the proposal? -1. If it were a valid identifier, $ would look even more confusing when used as a type name. I’d rather see $ used as an operator. > * Is the problem being addressed significant enough to warrant a change to > Swift? > * Does this proposal fit well