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

[Richard Wei via swift-evolution]

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 conversation, there has been significant 
> objection to the idea of requiring a ‘default’ for switches over enums that 
> are non-exhaustive.
> 
> This whole discussion is happening because the ABI stability work is 
> introducing a new concept to enums - invisible members/inhabitants (and 
> making them reasonably prominent).  A closely related feature is that may 
> come up in the future is "private cases”.  Private cases are orthogonal to 
> API evolution and may even occur on one that is defined to be exhaustive.
> 
> Private cases and non-exhaustive enums affect the enum in the same way: they 
> say that the enum can have values that a client does not know about.  Swift 
> requires switches to process *all* of the dynamically possible values, which 
> is why the original proposal started out with the simplest possible solution: 
> just require ‘default' when processing the cases.
> 
> 
> The problems with “unknown case:”
> 
> The popular solution to this probably is currently being pitched as a change 
> to the proposal (https://github.com/apple/swift-evolution/pull/777 
> ) which introduces a new 
> concept “unknown case” as a near-alias for ‘default’:
> https://github.com/jrose-apple/swift-evolution/blob/60d8698d7cde2e1824789b952558bade541415f1/proposals/0192-non-exhaustive-enums.md#unknown-case
>  
> 
> 
> In short, I think this is the wrong way to solve the problem.  I have several 
> concerns with this:
> 
> 1) Unlike in C, switch is Swift is a general pattern matching facility - not 
> a way of processing integers.  It supports recursive patterns and values, and 
> enums are not necessarily at the top-level of the pattern.   
> https://github.com/apple/swift/blob/master/docs/PatternMatching.rst is a 
> document from early evolution of Swift but contains a good general 
> introduction to this.
> 
> 2) Swift also has other facilities for pattern matching, including ‘if case’. 
>  Making switch inconsistent with them is not great.
> 
> 3) As pitched, “unknown case” will match *known* cases too, which is (in my 
> opinion :-) oxymoronic.
> 
> 4) “unknown case:” changes the basic swift grammar (it isn’t just a modifier 
> on case) because case *requires* a pattern.  A better spelling would be 
> “unknown default:” which is closer to the semantic provided anyway.
> 
> 5) It is entirely reasonable (though rare in practice) to want to handle 
> default and unknown cases in the same switch.
> 
> 
> For all the above reasons, ‘unknown case:' becomes a weird wart put on the 
> side of switch/case, not something that fits in naturally with the rest of 
> Swift.
> 
> 
> Alternative proposal:
> 
> Instead of introducing a new modifier on case/switch, lets just introduce a 
> new pattern matching operator that *matches unknown cases*, called “#unknown” 
> or “.#unknown” or something (I’m not wed to the syntax, better suggestions 
> welcome :).
> 
> In the simple case most people are talking about, instead of writing “unknown 
> case:” you’d write “case #unknown:” which isn’t much different.  The nice 
> thing about this is that #unknown slots directly into our pattern matching 
> system.  Here is a weird example:
> 
> switch someIntEnumTuple {
> case (1, .X):   … matches one combination of int and tuple...
> case (2, .Y):   … matches another combination of int and tuple...
> case (_, #unknown): …  matches any int and any unknown enum case ...
> case default:  … matches anything ...
> }
> 
> Furthermore, if you have a switch that enumerates all of the known cases and 
> use #unknown, then it falls out of the model that new cases (e.g. due to an 
> SDK upgrade or an updated source package) produces the existing build error.  
> As with the original proposal, you can always choose to use “default:” 
> instead of “case #unknown:” if you don’t like that behavior.
> 
> Of course, if you have an exhaustive enum (e.g. one defined in your own 
> module or explicitly marked as such) then #unknown matches nothing, so we 
> should warn about it being pointless.
> 
> 
> This addresses my concerns above:
> 
> 1) This fits into patterns in recursive positions, and slots directly into 
> the existing grammar for patterns.  It would be a very simple extension to 
> the compiler instead of a special case added to switch/case.
> 
> 2) Because it slots into the pattern grammar, it works directly with 'if 
> case’ and the other pattern matching stuff.
> 
> 3) Doesn’t match known cases.
> 
> 4) Doesn’t change the 

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

[Richard Wei via swift-evolution]

> 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 power, implicitness vs explicitness, intentionality vs 
>>> accidental behavior, etc.  For example, in very early discussions about 
>>> Swift generics, some folks where strong proponents of protocol conformance 
>>> being fully implicit: satisfying all the requirements of a protocol meant 
>>> that you conformed to it, even if you didn’t explicitly “inherit” from it.
>>> 
>>> This is obviously not the design we went with over the long term, and I’m 
>>> glad we didn’t.
>> 
>> I get that, but an attribute in particular would be just as explicit as a 
>> protocol conformance.
> 
> Sure, I’m not attached to spelling.  I think that conformance is the right 
> way to do this (following the pattern of the other ExpressibleBy etc types), 
> but if you have a compelling argument for some specific spelling, I’m more 
> than happy to discuss it.

I completely agree that protocol conformance is the right away to do it. One 
similar approach is Scala’s Dynamic 
 
protocol.

I can’t think of a good “-able” word for this. "DynamicMemberLookupProtocol" is 
probably good enough IMO.

-Richard

> 
>>> I think that DynamicMemberLookup requiring conformance is the same thing: 
>>> it makes it explicit that the behavior is intentional, and it allows 
>>> somewhat better error checking (if you conform to the protocol but don’t 
>>> implement the (implicitly known) requirement, you DO get an error).  That 
>>> said, this is just my opinion.  
>> 
>> So you envision that the compiler knows that 
>> `DynamicMemberLookupProtocol`-conforming types ought to have 
>> `subscript(dynamicMember:)` members, and these members ought to have certain 
>> traits (unary, ExpressibleByStringLiteral parameter, etc.), and it should 
>> enforce those traits, even though there's no matching requirement in the 
>> protocol?
> 
> Yes, this is implemented in the patch, it is a straight-forward additional 
> check in protocol conformance.
> 
> Keep in mind that the compiler has other similar things for features that are 
> not expressible in the Swift type system, e.g. the type(of:) function.
> 
>> That seems like a lot of compiler magic to attach to a particular protocol. 
>> A `@dynamicMember` attribute would have a similar amount of magic, but 
>> people *expect* that kind of magic from an attribute. For instance, the 
>> `@objc` attribute places lots of conditions on the types of parameters, 
>> etc., and nobody is surprised by that.
> 
> I don’t really think that’s the case.  Attributes have their place, for sure, 
> but there in high precedent for Protocols providing exposing language 
> features to types.
> 
>> 
>> Other reasons to prefer an attribute:
>> 
>> * I can't think of a use case where you would want dynamic members but not 
>> want to make the subscript itself accessible. If `@dynamicMember` could be 
>> applied to any subscript, then you could use any label (or no label) for 
>> sugar-free use of the dynamic functionality. For instance, the JSON example 
>> could decorate its existing subscript instead of introducing a redundant one:
> 
> I see the small advantage, but isn’t precedented at all.  The ExpressibleBy 
> protocols require redeclaring redundant methods just like this.
> 
>> * If we eventually want to support multiple subscripts with different types 
>> (either by using different return types, 
> 
> This is already supported in the patch, and the patch includes a test case.
> 
>> Basically, you're using a hammer to drive a screw. Why not use a screwdriver 
>> instead?
> 
> I don’t see a connection between this rhetorical mechanic and the topic at 
> hand :-)
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

> 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 expression.  Modeling 
 everything as throws in Swift would be super-annoying and unergonomic for 
 the programmer, because we'd require 'try' everywhere.  Thoughts on what 
 to do about that are welcome!
>>> 
>>> Requiring ‘try’ on every statement is annoying, but not having the ability 
>>> to catch python exceptions is annoying too. We could probably make python 
>>> exception handling an opt-in feature. For example:
>>> 
>>> try Python.do {
>>> let a = np.array([1, 2, 3])
>>> let b = np.array([[2], [4]])
>>> print(a.dot(b)) // matrix mul with incompatible shapes
>>> }
>>> catch let error as PythonException {
>>> // Handle PythonError.valueError(“objects are not aligned”)
>>> }
>> 
>> To correct my example:
>> 
>> do {
>> try Python.do {
>> let a = np.array([1, 2, 3])
>> let b = np.array([[2], [4]])
>> print(a.dot(b)) // matrix mul with incompatible shapes
>> }
>> }
>> catch let error as PythonException {
>> // Handle PythonError.valueError(“objects are not aligned”)
>> }
>> 
>> Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.
> 
> That’s a super interesting way to model this.  I’ll need to ponder on it 
> more, but  it is certainly a nice ergonomic solution.
> 
> Question though: how does it work?  Say the first np.array call threw a 
> python exception:
> 
>> try Python.do {
>> let a = np.array([1, 2, 3])
>> let b = np.array([[2], [4]])
>> print(a.dot(b)) // matrix mul with incompatible shapes
>> }
> 
> 
> We can definitely make the python glue code notice it, catch it and squirrel 
> it away somewhere, but without compiler hacks we couldn’t make it jump out of 
> the closure.  This means that np.array would have to return something, and 
> the calls below it would still execute, or am I missing something?

We make PythonObjects internally nullable (only in the exception-caught state). 
The second np.array would just return a null PythonObject.

To be specific, we define three states in the python overlay:
- Normal state: PythonObjects are guaranteed to be non-null. Any exception 
traps.
- Exception-catching state: PythonObjects are still guaranteed to be non-null. 
Any exception triggers the exception-caught state.
- Exception-caught state: PythonObjects are nullable — all python expressions 
return a null PythonObject.

The exception-catching state is entered during the execution of Python.do’s 
body.

-Richard

> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

> On Nov 1, 2017, at 03:14, Richard Wei via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
>> On Oct 31, 2017, at 21:31, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 a PythonObject or trapping.
>> 3) Make PythonObject itself nullable internally and return a null 
>> PythonObject.
>> 
>> #1 matches Python semantics directly, because it allows clients who care to 
>> check, but those who don't can ignore it.  The only problem I anticipate is 
>> that it will break things like:
>> 
>> let x = foo.bar
>> let y = x.thing   // fails, because x implicitly promoted to PythonObject?
>>  
>> #3 is gross and cuts against lots of things in Swift (recall when 
>> UnsafePointer itself was implicitly nullable, lets not go back to those bad 
>> old days).  I think that #2 is the least bad tradeoff.
> 
> I agree, PythonObject-or-die is the right trade-off.
> 
>> 
>> Yes, something like this is what I had in mind, but I think that 
>> functionName should only be required to be StringLiteralConvertible (no need 
>> to actually synthesize a real swift string).
>> 
>> 
>> Since you bring it up, Python exceptions will be annoying - As with other 
>> languages, Python can throw from an arbitrary expression.  Modeling 
>> everything as throws in Swift would be super-annoying and unergonomic for 
>> the programmer, because we'd require 'try' everywhere.  Thoughts on what to 
>> do about that are welcome!
> 
> Requiring ‘try’ on every statement is annoying, but not having the ability to 
> catch python exceptions is annoying too. We could probably make python 
> exception handling an opt-in feature. For example:
> 
> try Python.do {
> let a = np.array([1, 2, 3])
> let b = np.array([[2], [4]])
> print(a.dot(b)) // matrix mul with incompatible shapes
> }
> catch let error as PythonException {
> // Handle PythonError.valueError(“objects are not aligned”)
> }

To correct my example: 

do { 
try Python.do {
let a = np.array([1, 2, 3])
let b = np.array([[2], [4]])
print(a.dot(b)) // matrix mul with incompatible shapes
}
}
catch let error as PythonException {
// Handle PythonError.valueError(“objects are not aligned”)
}

Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.

-Richard

> 
> Python.do enables exception handling for statements in the body, declared as
> func `do`(_ body: () throws -> T) throws -> T
> 
> When we execute python-throwing statements inside a Python.do{}, 
> PythonException gets thrown. Otherwise, it traps.
> 
> The ‘Python.do’ function would ask the python overlay to enter an 
> "error-catching" state when executing the body closure. We make PythonObjects 
> internally nullable, but guarantee that they are non-null (or trap) when the 
> overlay is not in the “error-caught” state. When a python exception is thrown 
> in the error-catching state, the overlay enters the error-caught state and 
> propagates null through any python computation in the body closure. After the 
> body is executed, throw that python exception.
> 
> However, if there’s a throwing Swift statement after the throwing python 
> statement in the body, the python exception won’t be caught first… So having 
> the body as a non-throwing closure may be a better idea.
> 
> -Richard
> 
>> 
>>> 
>>> class Dog:
>>> 
>>> def __init__(self, name):
>>> self.name = name
>>> self.tricks = []# creates a new empty list for each dog
>>> 
>>> def add_trick(self, trick):
>>> self.tricks.append(trick)
>>> 
>>> With your don’t-modify-the-compiler approach, how can I create a Dog 
>>> instance and add a trick? I probably need to look up the class by name, 
>>> call __init__ manually, etc.
>>> 
>>>   let dogClass = python_getClassByName(“Dog”) // implemented in the Python 
>>> “overlay’, I guess
>>>   let dog = python_createInstance(dogClass)  // implemented in the Python 
>>> “overlay’, I guess
>>>   dog.__init__(“Brianna”)  // uses CustomCallable’s callMember
>>>   dog.add_trick(“Roll over”)  // uses CustomCallable’s callMember
>> 
>> I-am-not-a-python-expert, but I'd expect this to work:
>> 
&g

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

[Richard Wei via swift-evolution]

> 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 a PythonObject or trapping.
> 3) Make PythonObject itself nullable internally and return a null 
> PythonObject.
> 
> #1 matches Python semantics directly, because it allows clients who care to 
> check, but those who don't can ignore it.  The only problem I anticipate is 
> that it will break things like:
> 
> let x = foo.bar
> let y = x.thing   // fails, because x implicitly promoted to PythonObject?
>  
> #3 is gross and cuts against lots of things in Swift (recall when 
> UnsafePointer itself was implicitly nullable, lets not go back to those bad 
> old days).  I think that #2 is the least bad tradeoff.

I agree, PythonObject-or-die is the right trade-off.

> 
> Yes, something like this is what I had in mind, but I think that functionName 
> should only be required to be StringLiteralConvertible (no need to actually 
> synthesize a real swift string).
> 
> 
> Since you bring it up, Python exceptions will be annoying - As with other 
> languages, Python can throw from an arbitrary expression.  Modeling 
> everything as throws in Swift would be super-annoying and unergonomic for the 
> programmer, because we'd require 'try' everywhere.  Thoughts on what to do 
> about that are welcome!

Requiring ‘try’ on every statement is annoying, but not having the ability to 
catch python exceptions is annoying too. We could probably make python 
exception handling an opt-in feature. For example:

try Python.do {
let a = np.array([1, 2, 3])
let b = np.array([[2], [4]])
print(a.dot(b)) // matrix mul with incompatible shapes
}
catch let error as PythonException {
// Handle PythonError.valueError(“objects are not aligned”)
}

Python.do enables exception handling for statements in the body, declared as
func `do`(_ body: () throws -> T) throws -> T

When we execute python-throwing statements inside a Python.do{}, 
PythonException gets thrown. Otherwise, it traps.

The ‘Python.do’ function would ask the python overlay to enter an 
"error-catching" state when executing the body closure. We make PythonObjects 
internally nullable, but guarantee that they are non-null (or trap) when the 
overlay is not in the “error-caught” state. When a python exception is thrown 
in the error-catching state, the overlay enters the error-caught state and 
propagates null through any python computation in the body closure. After the 
body is executed, throw that python exception.

However, if there’s a throwing Swift statement after the throwing python 
statement in the body, the python exception won’t be caught first… So having 
the body as a non-throwing closure may be a better idea.

-Richard

> 
>> 
>> class Dog:
>> 
>> def __init__(self, name):
>> self.name = name
>> self.tricks = []# creates a new empty list for each dog
>> 
>> def add_trick(self, trick):
>> self.tricks.append(trick)
>> 
>> With your don’t-modify-the-compiler approach, how can I create a Dog 
>> instance and add a trick? I probably need to look up the class by name, call 
>> __init__ manually, etc.
>> 
>>   let dogClass = python_getClassByName(“Dog”) // implemented in the Python 
>> “overlay’, I guess
>>   let dog = python_createInstance(dogClass)  // implemented in the Python 
>> “overlay’, I guess
>>   dog.__init__(“Brianna”)  // uses CustomCallable’s callMember
>>   dog.add_trick(“Roll over”)  // uses CustomCallable’s callMember
> 
> I-am-not-a-python-expert, but I'd expect this to work:
> 
>   let dogModule = Python.import("DogModule")
>   dogModule.Dog("jckarter").add_trick("SILGenGen”)
>   let dog = dogModule.Dog(“Brianna”)
>   dog.add_trick(“Roll over)
> 
> or equivalently:
> 
>   let Dog = Python.import(“DogModule.Dog")
>   Dog("jckarter").add_trick("SILGenGen”)
>   let dog = Dog(“Brianna”)
>   dog.add_trick(“Roll over)
> 
> Seems pretty nice to me, with zero “Swift compiler knowledge of Python” 
> required.
> 
> 
>> With compiler integration, 
>> 
>>  class Dog : PythonObject {
>>init(_ name: Pythonable)
>>func add_trick(_ trick: Pythonable)
>>  }
> 
> Something like this is possible, but would be substantially more work, be 
> substantially more invasive, and would set the precedent that every other 
> dynamic language would get support hacked directly into Swift.  The only 
> reason I can see this being useful is if we wanted to support the optional 
> typing annotations in Python.  While this would be "nice to have", I think 
> the cost/benefit tradeoff involved is totally wrong for Swift. 
> 
>> With either the true “Python importer” solution or this code-generation 
>> solution, you at least get some level of code 

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

[Richard Wei via swift-evolution]

+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. Either the call should not 
> require &, or this use of & should not require the method to be mutating. The 
> workaround of copying to a temporary variable is not viable (see sample 
> project in SR-4649).
> 
> Hope there’s some way this issue can be addressed sooner rather than later.
> 
> Thanks,
>  Anders Kierulf
> 
>> On Apr 20, 2017, at 1:10 PM, Anders Kierulf  wrote:
>> 
>> Summary: Currently, only mutable values can be passed to UnsafeRawPointer, 
>> except for a special case for arrays. That special case should be 
>> generalized, allowing any values to be passed to UnsafeRawPointer without 
>> using &.
>> 
>> The following code shows the inconsistency in passing values to 
>> UnsafeRawPointer:
>> 
>> var varArray = [Int](repeating: 0, count: 6)
>> var varTuple = (0, 0, 0, 0, 0, 0)
>> 
>> let letArray = [Int](repeating: 0, count: 6)
>> let letTuple = (0, 0, 0, 0, 0, 0)
>> 
>> func get(_ pointer: UnsafeRawPointer, at index: Int) -> Int {
>>   let a = pointer.bindMemory(to: Int.self, capacity: 6)
>>   return a[index]
>> }
>> 
>> // Array can be passed directly, automatically takes address.
>> _ = get(varArray, at: 2) // okay
>> _ = get(letArray, at: 2) // okay
>> 
>> // When explicitly taking address, can only pass mutable variables.
>> _ = get(, at: 2) // okay, but seems inconsistent
>> _ = get(, at: 2) // fails: & not allowed
>> 
>> // Passing tuple instead of array fails.
>> _ = get(varTuple, at: 2) // fails: wrong type
>> _ = get(letTuple, at: 2) // fails: wrong type
>> 
>> // Adding & to pass a tuple only works for mutable values. Having to
>> // pass the address using & means that any methods calling this must
>> // be mutating, even though they don't mutate.
>> _ = get(, at: 2) // okay, but forces mutating
>> _ = get(, at: 2) // fails: cannot pass immutable value
>> 
>> Passing a value to an UnsafeRawPointer parameter should not require use of 
>> &, as that forces all code calling it to be mutating. Having a special case 
>> for array also doesn't make sense, as the idea of UnsafeRawPointer is that 
>> we're interpreting that memory content as whatever we want. Logged as 
>> SR-4649.
>> 
>> Proposal:
>> - Never require & when passing value to UnsafeRawPointer.
>> - Always require & when passing value to UnsafeMutableRawPointer.
>> 
>> (Fixed size arrays are still needed, but with this tweak, workarounds can be 
>> made to work.)
>> 
>> Anders Kierulf
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

> 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 
> Swift?
Yes, esp when executables go into platform subfolders in Swift 4.
> Does this proposal fit well with the feel and direction of Swift?
Yes.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Compares well. It’s very easy to use.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A reasonably thorough read.

-Richard

> On May 16, 2017, at 08:09, Daniel Dunbar via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0179: Swift `run` Command begins now and runs through May 
> 25th, 2017.
> 
> The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md
>  
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-build-dev and swift-evolution mailing lists at
> 
>   https://lists.swift.org/mailman/listinfo/swift-build-dev 
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md
>  
> 
> Reply text
> 
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> Daniel Dunbar (Review Manager)
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

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 Apr 17, 2017, at 16:07, Jens Persson via swift-evolution 
>  wrote:
> 
> I've used code like the following example in similar situations and I've 
> always (after a lot of profiling, trial and error) managed to get the (ugly) 
> Swift code as fast as the C/C++ code.
> 
> struct UnsafeStatic19x19 {
> var storage: (
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E,
> E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E, E
> )
> subscript(x: Int, y: Int) -> E {
> get {
> // No index out of bounds check
> var m = self // <-- This workaround will be optimized away.
> return withUnsafeBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> return $0.load(fromByteOffset: byteOffset, as: E.self)
> }
> }
> set {
> withUnsafeMutableBytes(of: ) {
> let byteOffset = MemoryLayout.stride * (x + y*19)
> $0.storeBytes(of: newValue, toByteOffset: byteOffset, as: 
> E.self)
> }
> }
> }
> }
> 
> It isn't pretty but it works (haven't tried this code example though, but you 
> get the idea).
> 
> 
> I wish it was possible to write something like
> struct StaticArray {
> ...
> }
> instead (a statically allocated array with type-level Count as well as 
> Element).
> 
> /Jens
> 
> 
> On Mon, Apr 17, 2017 at 7:52 PM, Anders Kierulf via swift-evolution 
> > wrote:
> Swift needs a datatype that contains a fixed number of a given type; 
> basically a simple fixed-size array.
> 
> Motivation: I’ve been porting code for Monte Carlo Tree Search in my 
> Go-playing program from C++ to Swift. Performance is crucial for this code, 
> as more simulations lead to better play. After the initial port, the Swift 
> code was more than 10x slower than my C++ code. After several weeks of 
> optimizing, profiling, and digging through disassembly, I’ve gotten to within 
> a factor of 2. Most of that gain came from using the ugly workaround of 
> importing fixed-size arrays from C.
> 
> My app is designed for a 19x19 (or smaller) Go board, not an arbitrary N x N 
> board, so I don’t want to pay the high cost of variable-size data structures 
> in the lowest levels of my app. Most apps are not like this, and most of my 
> app is not, but this kernel of my app needs to be fast. Heap allocations, 
> reference counting, and indirections all slow down the code. I just need a 
> fixed size of memory that I can access like an array, and Swift doesn’t let 
> me do that.
> 
> Workaround: By importing an array from C, I can allocate a blob of memory on 
> the stack or include it in a struct. I can then use UnsafeRawPointer to 
> access that blob like an array (see details in SR-4548). This is ugly, but it 
> works, and it is much faster than using a Swift array. However, I’m stymied 
> by SR-4542, which causes mutability to spread like a plague through client 
> code.
> 
> (SR-4542: Calling a function taking an UnsafeRawPointer forces the parameter 
> to be passed as inout, which means the method must be mutating. 
> UnsafeMutableRawPointer should require inout, UnsafeRawPointer should not.)
> 
> Proposal: UnsafeMutablePointer almost provides what I need. However, it can 
> only allocate memory on the heap, or it can take a given blob of memory and 
> interpret it as something else. What’s missing is a way to allocate typed 
> memory of a certain size on the stack or in a struct. For example, something 

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

[Richard Wei via swift-evolution]

+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 
>> > wrote:
>> 
>> +1. Perfect. Let's not bikeshed this and get it done!
> 
> 
> Sorry, I'm going to have to insist on bikeshedding.
> 
> `equalTo:` is kind of ugly and has no precedent in the standard library. 
> Similar APIs seem to either leave the parameter unlabeled or use `of:` (as in 
> `index(of:)`). I think unlabeled is probably the right answer here.
> 
> The main shortcoming I can see is that if you see:
> 
>   array.removeAll(3)
> 
> You might think `3` is either an index or a count. But neither of those 
> actually make sense:
> 
> * It can't be an index because then `All` would have no meaning. There's only 
> ever one thing at a given index. Besides, indices are almost always marked 
> with `at:` or another parameter label.
> * It can't be a count because `All` is already a count. What could "remove 
> all 3" possibly mean if the array doesn't happen to have three elements?
> 
> And this is only a problem if the value happens to be an integer. If it's 
> anything else, the type makes clear that this can't possibly be an index or 
> count; it must be an element.
> 
> (But if you really do think this is insurmountable, `removeAll(of: 3)` *is* 
> impossible to misinterpret and fits in better than `removeAll(equalTo:)`.)
> 
> (P.S. The existing oddness of `removeFirst(_:)` compared to `removeFirst()` 
> and `removeAll()` is why I proposed last year that it be renamed to 
> `removePrefix(_:)`, which matches the count-taking `prefix(_:)` method.)
> 
> --
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

`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 
`forEach` conveys the sense of iteration, while the “all” in `forAll` conveys 
both iteration and conjunction.

-Richard

> On Apr 2, 2017, at 00:05, Robert Bennett via swift-evolution 
>  wrote:
> 
> It figures, the hardest thing to pick is the name of this function…
> 
> I like forAll the best so far, but I worry that it sounds too much like 
> forEach and would be confusing.
> 
> What does everyone think of withoutException? nums.withoutException(isEven) 
> and nums.withoutException { isEven($0) } make their purpose clear, and even 
> make clear what happens for an empty Collection.
> 
> Other options that come to mind that I am less enthusiastic about:
> 
> nums.every(satisfies: isEven) / nums.every { isEven($0) }
> nums.entirely(isEven) / nums.entirely { isEven($0) }
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

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 Bool.
> 
> Perhaps the function name should be question-like?
> 
> Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or maybe 
> even just `satisfies(condition:)`
> The question-like modifier/verb is necessary to suggest a Bool and IMO not a 
> needless word.
> 
> Regards,
> Will Stanton
> 
>> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hopefully non-controversial, aside from the naming of the method and 
>> arguments, about which controversy abounds
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

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. 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 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 > >> > wrote:
>> >>
>> >>
>> >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution 
>> >>> > wrote:
>> >>>
>> >>> I like this idea.  I think you made the right choice of syntax given the 
>> >>> alternatives considered.  To me `foo(_)` and `foo(:)` equally imply 
>> >>> presence of an argument.  The former looks like an anonymous (unnamed) 
>> >>> argument and the latter includes the colon which only follows an 
>> >>> argument.  Between the two `foo(:)` is the better choice because it 
>> >>> doesn’t look like a pattern as has been pointed out.
>> >>>
>> >>> I’m going to do a little brainstorming to try and come up with something 
>> >>> that works and doesn’t imply an argument at all but suspect I’ll come up 
>> >>> empty handed.
>> >>
>> >> What about “foo(Void)”? It might be fairly easily confused with 
>> >> “foo(:Void)”, but in practice, how likely is it for someone to declare 
>> >> both `foo()` and `foo(_: Void)`?
>> >
>> > I almost threw out `foo(Void)` and `foo(Never)` as ideas.  There is at 
>> > least one problem with these.  We will hopefully eventually get rid of the 
>> > need to say `.self` in expressions like `Int.self`.  If we are able to do 
>> > that then `foo(Void)` and `foo(Never)` are syntactically valid function 
>> > calls.
>> 
>> Oh, good point! Hrmm… “foo(#null)”/“foo(#nullary)"? I can’t imagine either 
>> of those would ever be valid function calls, and they get the point across 
>> (the later more than the former, but it’s more to type). I don’t like that 
>> syntax for the name of “shortest” version of the function isn’t shorter than 
>> the syntax of the name for other versions of the function, though.
>> 
>> - Dave Sweeris
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

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 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  >> > wrote:
> >>
> >>
> >>> On Feb 22, 2017, at 7:48 AM, Matthew Johnson via swift-evolution 
> >>> > wrote:
> >>>
> >>> I like this idea.  I think you made the right choice of syntax given the 
> >>> alternatives considered.  To me `foo(_)` and `foo(:)` equally imply 
> >>> presence of an argument.  The former looks like an anonymous (unnamed) 
> >>> argument and the latter includes the colon which only follows an 
> >>> argument.  Between the two `foo(:)` is the better choice because it 
> >>> doesn’t look like a pattern as has been pointed out.
> >>>
> >>> I’m going to do a little brainstorming to try and come up with something 
> >>> that works and doesn’t imply an argument at all but suspect I’ll come up 
> >>> empty handed.
> >>
> >> What about “foo(Void)”? It might be fairly easily confused with 
> >> “foo(:Void)”, but in practice, how likely is it for someone to declare 
> >> both `foo()` and `foo(_: Void)`?
> >
> > I almost threw out `foo(Void)` and `foo(Never)` as ideas.  There is at 
> > least one problem with these.  We will hopefully eventually get rid of the 
> > need to say `.self` in expressions like `Int.self`.  If we are able to do 
> > that then `foo(Void)` and `foo(Never)` are syntactically valid function 
> > calls.
> 
> Oh, good point! Hrmm… “foo(#null)”/“foo(#nullary)"? I can’t imagine either of 
> those would ever be valid function calls, and they get the point across (the 
> later more than the former, but it’s more to type). I don’t like that syntax 
> for the name of “shortest” version of the function isn’t shorter than the 
> syntax of the name for other versions of the function, though.
> 
> - Dave Sweeris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

+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 
>> > wrote:
>> 
>> How would we all feel about allowing multiple modules with one import 
>> statement? 
>> 
>> Eg: the option to write
>> 
>> import Cocoa, Foo, Bar.Baz  
>> 
>> in addition to just:
>> 
>> import Cocoa   
>> import Foo 
>> import Bar.Baz 
>> 
>> When I'm writing smaller files that import a few modules, I'd  prefer to 
>> lump the imports together like this. Doesn't seem like a feature that would 
>> require much effort to implement either.
> 
> I'm fine with this. I'd also like `import as` to handle namespacing 
> simplification and conflict resolution
> 
> `import Bar.Baz as Bif`
> 
> -- E
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Richard Wei via swift-evolution]

> * 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 with the feel and direction of Swift?
No.

> * If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
I don’t think this is a Swifty style.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
More than a quick reading.

-Richard

> On Oct 14, 2016, at 14:59, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0144: Allow Single Dollar Sign as a Valid Identifier" 
> begins now and runs through October 18. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution