Re: [swift-evolution] Abstract methods

[Gwendal Roué via swift-evolution]

> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
> I think we should beef up protocols a little bit so that they can serve the 
> role of abstract classes. 

That would be great.

Back in the day, the proposal SE-0026 "Abstract classes and methods" was 
deferred, with the following rationale: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/56.html

This rationale is great because it lists a few use cases for abstract class 
that protocols can't mimic today.

Gwendal

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

Re: [swift-evolution] Adding Result to the Standard Library

[Chris Lattner via swift-evolution]

> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>  wrote:
> 
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
I’m generally supportive of this, but the design of such a thing forces another 
contentious issue: whether the error handling model should be extended to 
support "typed throws”.  Without result, we can carry on pushing the "typed 
throws” debate down the road.  Adding it would force that issue to be decided, 
which is complicated.

-Chris


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

Re: [swift-evolution] Abstract methods

[Brent Royal-Gordon via swift-evolution]

> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution 
>  wrote:
> 
> Swift architectures use much less inheritance (and class types) in general 
> than equivalent c++ architectures. personally i have never been in a 
> situation where i didn’t need a pure abstract method that was better declared 
> as a protocol requirement.


I think we should beef up protocols a little bit so that they can serve the 
role of abstract classes. That would make for a nice, clean separation: 
anything abstract is a protocol, while anything concrete is a class (or struct 
or enum).

What would protocols need in order to support everything abstract classes can 
do? First, we'd probably need to extend class constraints to allow a protocol 
to require you to subclass a given base class:

// Hypothetical replacement for UIControl.
protocol UIControl: UIView {
func sendAction(_ action: Selector, to target: Any?, for event: 
UIEvent)
}

extension UIControl {
func sendAction(_ action: Selector, to target: Any?, for event: 
UIEvent) {
UIApplication.shared.sendAction(action, to: target, 
from: self, for: event)
}
}

Maybe allow them to declare automatically-added storage, perhaps even private 
to the protocol:

protocol UIControl: UIView {
@automatic
private var actions: [UIControlEvents: [(target: Any?, action: 
Selector)]] = [:]

func sendAction(_ action: Selector, to target: Any?, for event: 
UIEvent)
}

extension UIControl {
func sendActions(for controlEvents: UIControlEvents) {
for (event, pairs) in actions where 
event.contains(controlEvents) {
for pair in pairs {
sendAction(pair.action, to: 
pair.target, for: UIApplication.shared.currentEvent)
}
}
}

func sendAction(_ action: Selector, to target: Any?, for event: 
UIEvent) {
UIApplication.shared.sendAction(action, to: target, 
from: self, for: event)
}
}

Probably something like `super` for when you want to override a default 
implementation but still call it:

class MyButton: UIControl {
func sendAction(_ action: Selector, to target: Any?, for event: 
UIEvent) {
print("Sending \(action) to \(target)")
super(UIControl).sendAction(action, to: target, for: 
event)
}
}

These are all solid features that would be great additions to protocols, even 
when they're *not* replacing abstract classes.

-- 
Brent Royal-Gordon
Architechies

___
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

[Chris Lattner via swift-evolution]

> On Nov 2, 2017, at 1:58 PM, Rocky Wei via swift-evolution 
>  wrote:
> 
> Hi Chris and everyone else,
> 
> So PerfectlySoft made Perfect-Python months ago to help Swift import python 
> objects and libraries. However, it may reduce the strong type checking. Any 
> idea to avoid it?
> 
> https://github.com/PerfectlySoft/Perfect-Python 
> 
Cool, I wasn’t aware of this.  It looks like a straight-forward wrapper for the 
Python C API.  

Here are some random questions:

why do you make the conversions from Python types to Swift types non-failable?  
This init I’d expect to be failable, for example:
https://github.com/PerfectlySoft/Perfect-Python/blob/master/Sources/PerfectPython/PerfectPython.swift#L34
 



I understand that you’re wrapping PyObject* with a class to get ARC behavior, 
but why make it “open”?  What does subclassability mean for your PyObj type?
https://github.com/PerfectlySoft/Perfect-Python/blob/master/Sources/PerfectPython/PerfectPython.swift#L183


Why do you print errors when you throw, instead of including the details in the 
error that gets thrown?
https://github.com/PerfectlySoft/Perfect-Python/blob/master/Sources/PerfectPython/PerfectPython.swift#L223
 


Why include a fixed list of supported types, instead of using a protocol to 
make it extensible?
https://github.com/PerfectlySoft/Perfect-Python/blob/master/Sources/PerfectPython/PerfectPython.swift#L260
 


What’s this defer doing?
https://github.com/PerfectlySoft/Perfect-Python/blob/master/Sources/PerfectPython/PerfectPython.swift#L423
 


-Chris

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

Re: [swift-evolution] Adding Result to the Standard Library

[Xiaodi Wu via swift-evolution]

On Thu, Nov 2, 2017 at 9:36 PM, Jon Shier  wrote:

> > I would argue that a successful addition to the standard library *must*
> have such additional justification about why it needs built-in support. If
> it's already in use as a third-party library, and you're arguing that the
> third-party design is already quite satisfactory and there's no built-in
> support required, then that's fundamentally an argument that it *doesn't*
> need to be in the standard library.
>
> What? That doesn’t make any sense at all. I’ve written this
> proposal to get a very popular and useful type into the standard library
> exactly because it’s so popular and useful. It’s so popular and useful, in
> fact, that users are running into issues getting all of the third-party
> implementations to play well together. I’ll be adding more to the proposal
> about the general usefulness of the Result type tomorrow, but it has often
> been said on this mailing list that one of the ways a type can become part
> of the standard library is by becoming popular in the community.


No no no, that's often been said to be one of the ways to have something
accepted as a _new core library_ (like Foundation, Dispatch, etc.), not as
a part of the standard library. The Swift server API working group, for
example, is working on bootstrapping one or multiple such additional core
libraries.

The standard library is deliberately small, includes facilities essential
for the language itself requiring built-in support, and does *not* have a
goal of supplying all generally useful or sought-after functionality. This
is why, as the Swift Foundation project states, URL is appropriately part
of Foundation and *not* the standard library.


> My assertion is that Result has reached that point and so needs
> consideration for the benefit of not only all current users of the type,
> but the community in general.
>

I do think you have a good argument to make that error handling is
fundamentally a "language" and not a "library" feature. But you would need
to make the case convincingly by demonstrating how it benefits from
language features. Otherwise, it's a candidate for being part of some core
library but *not* a great candidate for the standard library.


> I could also be confused about what you mean about “built-in”
> support, or the types of things you’d think a standard library Result type
> should do that isn’t in the proposal. In that case, could you be much more
> specific about what additions you think it needs?
>

Built-in support could include such things as:
* language support for "unwrapping," analogous (though of course not
identical) to `?` and `!`
* compiler magic to reconcile `() throws -> Int` and `() -> Result` so
that one spelling can be used as an implementation for a protocol
requirement spelled differently, or one spelling can be used in a subclass
overriding a method spelled differently
* any other conveniences necessary to make interconversion between `() ->
Result`, `() throws -> T`, `() -> T?`, and `() -> T!` more fluid from
the caller side or from the library writer side

I am not saying that `Result` definitely needs these things, although I
suspect it could benefit from at least a few such well-designed language
features. In my view, a complete proposal for the _standard library_ would
look into these conveniences, evaluate different possible designs for each,
then discuss which most improve user ergonomics and cohesion of the
language.

The Swift Error Handling Rationale document itself mentions similar as well
as additional Result-related needs:

> A function to evaluate an error-producing closure and capture the result
as a Result.
> A function to unpack a Result by either returning its value or
propagating the error in the current context.
> A futures library that traffics in Result when applicable.
> An overload of dispatch_sync which takes an error-producing closure and
propagates an error in the current context.
> etc.

In proposing the addition of `Result`, some overarching vision needs to be
articulated that firstly answers the question of: what is or should be part
of the "etc." mentioned above, and how must we design `Result` and any
accompanying language features so that we can eventually get there?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

> On Nov 2, 2017, at 7:52 PM, Noah Desch  wrote:
> 
> 
> IMO the ledger isn’t just about access control, it’s also about having a 
> convenient (and guaranteed correct, due compiler enforcement) place to see 
> where the rest of your class is defined. 

I have worked on several large code bases in C# that made extensive use of 
partial classes. This was never a problem. No one ever tried to put a partial 
class where it didn’t belong. 

Would it be an error to have an entry in the “ledger” but not a corresponding 
implementation?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Noah Desch via swift-evolution]

IMO the ledger isn’t just about access control, it’s also about having a 
convenient (and guaranteed correct, due compiler enforcement) place to see 
where the rest of your class is defined. 

I’m +1 on the ledger and partial classes in general. I think extensions serving 
the dual purpose of extending other module’s classes, as well as an 
organizational tool for in-module classes has resulted in some bad choices and 
makes future development harder. Having a new construct for in-module class 
organization neatly solves the problem.

(I still want C++’s protected scope too though, in case there was any doubt). 


> On Nov 2, 2017, at 9:37 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> I will echo what several other people said in the previous discussion: you 
> have to trust your fellow developers. By declaring a class as “partial” you 
> are allowing that class to be extended elsewhere. Typically that would mean 
> in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It 
> should be highly discouraged to extend the class using partial from anywhere 
> else, and listing tools can enforce that if needed. But at the end of the day 
> if you can’t trust your fellow developers not to do that then you can’t trust 
> them not to add a new name to the ledger either.
> 
> And in case someone was wondering why I’m ok with this and not the 
> “classprivate" idea, the key difference here is that this is opt-in. I’m 
> still not ok with a random extension being able to access private fields of 
> any class by default. Partial classes should be an exception for specific use 
> cases, not a default behavior.
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Eric Summers via swift-evolution]

Yeah.  There are so many pitfalls to passing parameters implicitly.  It only 
works for exceptions because the function is annotated with throws.

Eric

> On Nov 2, 2017, at 10:05 PM, Xiaodi Wu  wrote:
> 
> I think the use case is legitimate, but I'm uncomfortable with the proposed 
> solution. Firstly, because for the proposed use case it's not a "default" 
> parameter in that it's not overridable: you can't actually pass another 
> argument. Secondly, because you wouldn't want the two parameters of an infix 
> operator function, or the single parameter of a non-infix operator function, 
> to allow a default value (that totally gums up the distinction between 
> prefix, infix, and postfix operators). I agree with Eric that the use case 
> feels like it calls for a "macro-like" solution.
> 
> On Thu, Nov 2, 2017 at 7:50 PM, Eric Summers via swift-evolution 
> > wrote:
> I think this makes more sense as part of a hygienic macro system.  These 
> “hidden” parameters could be made available to standard functions using some 
> sort of convention to exclude them from autocompletion.
> 
> Eric
> 
> 
>> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> I like this idea as it's presented here, for the debugging/logging reasons 
>> that you stated.
>> 
>> Should we tighten the shackles a little be to validate that *only* the 
>> special #file/#line/#function directives can be permitted for these extra 
>> parameters? I'm struggling to think of a case where we would want to allow 
>> something else, since there's no way to provide the values for them in a 
>> standard call.
>> 
>> 
>> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
>> > wrote:
>> Hi SE,
>> 
>> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
>> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
>> and #line where the operators are used to make debugging their use a lot 
>> easier.
>> 
>> For example, given something the unwrap-or-die operator 
>> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>>  
>> ),
>>  you’d want to capture the #file and #line so you could pass it on to the 
>> underlying call to fatalError().
>> 
>> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
>> great to be able to capture the file and line where the operator is used so 
>> you can quickly triage the bug in your code.
>> 
>> Unfortunately, Swift has the hard limit the the implementations of unary 
>> operators may have one-and-only-one parameter, and that binary operators may 
>> only have two parameters.
>> 
>> I’d like to propose a very minor change to Swift, whereby operator 
>> implementations may have more than their one or two parameters, provided 
>> that all subsequent parameters come with a default value. This would make it 
>> trivial to add in #file, #line, #function, etc to your operator 
>> implementations, which you can then capture for your own purposes.
>> 
>> An implementation of this change, with passing tests, can be found here: 
>> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>>  
>> 
>> 
>> Dave
>> ___
>> 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 
>> 
> 
> 
> ___
> 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] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

> I would argue that a successful addition to the standard library *must* have 
> such additional justification about why it needs built-in support. If it's 
> already in use as a third-party library, and you're arguing that the 
> third-party design is already quite satisfactory and there's no built-in 
> support required, then that's fundamentally an argument that it *doesn't* 
> need to be in the standard library.

What? That doesn’t make any sense at all. I’ve written this proposal to 
get a very popular and useful type into the standard library exactly because 
it’s so popular and useful. It’s so popular and useful, in fact, that users are 
running into issues getting all of the third-party implementations to play well 
together. I’ll be adding more to the proposal about the general usefulness of 
the Result type tomorrow, but it has often been said on this mailing list that 
one of the ways a type can become part of the standard library is by becoming 
popular in the community. My assertion is that Result has reached that point 
and so needs consideration for the benefit of not only all current users of the 
type, but the community in general. 
I could also be confused about what you mean about “built-in” support, 
or the types of things you’d think a standard library Result type should do 
that isn’t in the proposal. In that case, could you be much more specific about 
what additions you think it needs?



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

Re: [swift-evolution] Adding Result to the Standard Library

[Xiaodi Wu via swift-evolution]

On Thu, Nov 2, 2017 at 7:04 PM, Jon Shier  wrote:

> I’m certainly willing to adjust API to better match convention and
> guidelines. However, part of the proposal’s basis is the popularity of the
> Alamofire implementation (which is rather similar to the antitypical one in
> regards to additional API offered). Adding special syntax for it isn’t
> really something I want to do, as ever bit of that needs additional
> justification beyond the fact that’s it’s already in use.
>

On the contrary, every addition to the standard library must justify why it
must be in *the standard library*, as opposed to another core library or a
third-party library. Consider this standard articulated in the Foundation
README:

> How do we decide if something belongs in the standard library or
Foundation?

> In general, the dividing line should be drawn in overlapping area of what
people consider the language and what people consider to be a library
feature. For example, Optional is a type provided by the standard library.
However, the compiler understands the concept to provide support for things
like optional-chaining syntax. The compiler also has syntax for creating
Arrays and Dictionaries. On the other hand, the compiler has no built-in
support for types like URL. URL also ties into more complex functionality
like basic networking support. Therefore this type is more appropriate for
Foundation.

I would argue that a successful addition to the standard library *must*
have such additional justification about why it needs built-in support. If
it's already in use as a third-party library, and you're arguing that the
third-party design is already quite satisfactory and there's no built-in
support required, then that's fundamentally an argument that it *doesn't*
need to be in the standard library.

On Nov 2, 2017, at 8:01 PM, Xiaodi Wu  wrote:
>
> This is clearly a fine addition to the standard library; even Swift's
> Error Handling Rationale (https://github.com/apple/swift/blob/master/docs/
> ErrorHandlingRationale.rst) mentions such an addition
>
> What separates standard library types from other types is that they have
> language level support, and the wrapping and unwrapping syntax here could
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
> incidentally--is so much less elegant in comparison to `?` and `!` for
> optionals (not that `Result` should use the exact such syntax for a
> distinct operation)). It would be a shame to transpose a third-party
> `Result` to the standard library without considering if any such tweaks
> would substantially improve ergonomics, interconversion with Optional and
> throws, etc.
>
>
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>> https://github.com/jshier/swift-evolution/blob/master/propos
>> als/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>>
>> ___
>> 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] Adding Result to the Standard Library

[Xiaodi Wu via swift-evolution]

On Thu, Nov 2, 2017 at 7:11 PM, Tony Allevato 
wrote:

> Proposing syntactic sugar for this at the same time would go a long way
> toward making me less reluctant to support it. As a type by itself, I don’t
> think it holds its weight in the standard library.
>
> The question that I’d want to see answered is, is it possible to make it
> so that these two functions are identical for all intents and purposes?
>
> func foo() throws -> Int
> func foo() -> Result
>
> Doing that at the call site is easy enough (the proposed implementation
> does much of that, but more could be done at the language level to remove
> the manual unwrapping), but I’m not sure how you reconcile the fact that,
> of those two declarations, an author *does* have to pick one to write.
>

Agree, issues such as this *must* be addressed for a successful `Result`
proposal. The resulting design should be highly coherent and reflect a
unitary vision of error handling; it cannot be merely a bolting-on of an
external Result type.


> One thing I can think of off the top of my head is forbid functions from
> returning Result<> but allow them to be created by assignment from a
> throwing function. That, however, seems like an arbitrary and just flat out
> bizarre limitation and I can’t really bring myself to support it.
>
> I guess the problem I want to avoid is that, even if you sugar away all
> the differences between Result<> and throwing when it comes to *calling*
> these functions, there would still be two ways to declare essentially the
> same function, and the choice of which someone uses becomes arbitrary and
> meaningless.
>
>
> On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This is clearly a fine addition to the standard library; even Swift's
>> Error Handling Rationale (https://github.com/apple/
>> swift/blob/master/docs/ErrorHandlingRationale.rst) mentions such an
>> addition
>>
>> What separates standard library types from other types is that they have
>> language level support, and the wrapping and unwrapping syntax here could
>> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
>> incidentally--is so much less elegant in comparison to `?` and `!` for
>> optionals (not that `Result` should use the exact such syntax for a
>> distinct operation)). It would be a shame to transpose a third-party
>> `Result` to the standard library without considering if any such tweaks
>> would substantially improve ergonomics, interconversion with Optional and
>> throws, etc.
>>
>>
>>
>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Swift-Evolution:
>>> I’ve written a first draft of a proposal to add Result to the
>>> standard library by directly porting the Result type used in Alamofire
>>> to the standard library. I’d be happy to implement it (type and tests for
>>> free!) if someone could point me to the right place to do so. I’m not
>>> including it directly in this email, since it includes the full
>>> implementation and is therefore quite long. (Discourse, please!)
>>>
>>> https://github.com/jshier/swift-evolution/blob/master/
>>> proposals/0187-add-result-to-the-standard-library.md
>>>
>>>
>>> Thanks,
>>>
>>> Jon Shier
>>>
>>>
>>>
>>> ___
>>> 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
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Xiaodi Wu via swift-evolution]

I think the use case is legitimate, but I'm uncomfortable with the proposed
solution. Firstly, because for the proposed use case it's not a "default"
parameter in that it's not overridable: you can't actually pass another
argument. Secondly, because you wouldn't want the two parameters of an
infix operator function, or the single parameter of a non-infix operator
function, to allow a default value (that totally gums up the distinction
between prefix, infix, and postfix operators). I agree with Eric that the
use case feels like it calls for a "macro-like" solution.

On Thu, Nov 2, 2017 at 7:50 PM, Eric Summers via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this makes more sense as part of a hygienic macro system.  These
> “hidden” parameters could be made available to standard functions using
> some sort of convention to exclude them from autocompletion.
>
> Eric
>
>
> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I like this idea as it's presented here, for the debugging/logging reasons
> that you stated.
>
> Should we tighten the shackles a little be to validate that *only* the
> special #file/#line/#function directives can be permitted for these extra
> parameters? I'm struggling to think of a case where we would want to allow
> something else, since there's no way to provide the values for them in a
> standard call.
>
>
> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi SE,
>>
>> As I’ve been using my own custom operators like “?!”, “!!”, or operators
>> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file
>> and #line where the operators are used to make debugging their use a lot
>> easier.
>>
>> For example, given something the unwrap-or-die operator (
>> https://github.com/erica/swift-evolution/blob/
>> 2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md),
>> you’d want to capture the #file and #line so you could pass it on to the
>> underlying call to fatalError().
>>
>> Or, if you’re using a custom bind operator and something goes wrong, it’d
>> be great to be able to capture the file and line where the operator is used
>> so you can quickly triage the bug in your code.
>>
>> Unfortunately, Swift has the hard limit the the implementations of unary
>> operators may have one-and-only-one parameter, and that binary operators
>> may only have two parameters.
>>
>> I’d like to propose a very minor change to Swift, whereby operator
>> implementations may have more than their one or two parameters, provided
>> that all subsequent parameters come with a default value. This would make
>> it trivial to add in #file, #line, #function, etc to your operator
>> implementations, which you can then capture for your own purposes.
>>
>> An implementation of this change, with passing tests, can be found here:
>> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e
>> 9d70bfa697
>>
>> Dave
>> ___
>> 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
>
>
>
> ___
> 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] Revisiting SE-0132 Rationalizing Sequence end-operation names

[Xiaodi Wu via swift-evolution]

On Thu, Nov 2, 2017 at 7:26 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> During the Swift 3 cycle, I proposed SE-0132, "Rationalizing Sequence
> end-operation names". It was rejected because it needed revision and there
> was no time to do so. Since then, part of the proposal—partial ranges and
> the `RangeExpression` slicing protocol—has been adopted in SE-0172,
> "One-sided Ranges". I''d like to reopen discussion of the rest of the
> proposal.
>
> To refresh your memory, SE-0132 proposed systematically renaming a number
> of `Sequence` and `Collection` methods which operate on the beginning and
> end of a sequence. Many of these methods have names borrowed directly from
> functional programming; they use terminology in conflicting ways and don't
> follow our conventions for non-mutating method names. For example, consider
> the inconsistent and API Guideline-violating names of a few members which
> operate on the beginning of a sequence or collection:
>
> first   dropFirst()
>  removeFirst()
> prefix(_:)  dropFirst(_:)
>  removeFirst(_:)
> prefix(while:)  drop(while:)—
>
> These members could be renamed to form consistent "families" where a given
> term always meant the same thing:
>
> first   removingFirst() removeFirst()
> prefix(_:)  removingPrefix(_:)
> removePrefix(_:)
> prefix(while:)  removingPrefix(while:)  —
>
> The main question in my mind about this plan is source stability. Back
> during Swift 3, we broke compatibility willy-nilly, but today we're being a
> little more circumspect. I believe these names meet the criteria of being
> actively harmful—they are difficult to discover, so developers don't use
> these members even when they should, and many of them sound like mutating
> methods or are unclear about their purpose—but that still doesn't tell us
> how we should treat the old names.
>
> Basically, when should we introduce the new names?
>
> 1. Swift 4.1 (or whatever pre-Swift 5 version the proposal ends up
> landing in)
> 2. Swift 4.n (the version of Swift 5's compatibility mode for
> Swift 4)
> 3. Swift 5
>

(All of the following IMHO:)

Swift 4.1 or whatever is closest. The new names are very clear, and their
introduction doesn't impair backwards compatibility.


> And when should we deprecate the old ones?
>
> 1. Swift 4.1
> 2. Swift 4.n
> 3. Swift 5
> 4. Swift 6
> 5. Never
>

Deprecation warnings: Swift 5. Code continues to compile, and fix-its and a
migrator can get rid of the warning.
Removal of deprecated API: Swift 6; ABI stability may require these symbols
to continue to exist though.

I'm also open to discussion about whether this should be done at all,
> whether any additional methods should be included (or included methods
> should be left alone), whether the now-obsolete `prefix(from:)`
> `prefix(upTo:)`, and `prefix(through:)` methods should be left alone,
> deprecated, or removed, and whether this should be done in this proposal or
> a different one.
>

Could deprecate in Swift 5--don't feel strongly about this one. Definitely
a separate proposal.


> The original proposal, which lists all affected methods and explains the
> logic behind them, is available at  swift-evolution/blob/master/proposals/0132-sequence-end-ops.md>. Keep in
> mind that the parts about ranges have already been incorporated into Swift
> in a revised form, so you can ignore them.
>
> I'll get cracking on an implementation once we figure out what I should
> implement.
>
> Thanks!
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Adam Kemp via swift-evolution]

I will echo what several other people said in the previous discussion: you have 
to trust your fellow developers. By declaring a class as “partial” you are 
allowing that class to be extended elsewhere. Typically that would mean in an 
adjacent file named ClassName.Foo.swift (next to ClassName.swift). It should be 
highly discouraged to extend the class using partial from anywhere else, and 
listing tools can enforce that if needed. But at the end of the day if you 
can’t trust your fellow developers not to do that then you can’t trust them not 
to add a new name to the ledger either.

And in case someone was wondering why I’m ok with this and not the 
“classprivate" idea, the key difference here is that this is opt-in. I’m still 
not ok with a random extension being able to access private fields of any class 
by default. Partial classes should be an exception for specific use cases, not 
a default behavior.

> On Nov 2, 2017, at 5:18 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> to sum up. so far the feedback on this proposal was:
> 
> 1) generally in favour (e.g. to have ability of adding variables and 
> accessing privates at all)
> 
> 2) the name "continuation" is used for something else
> 
> 3) why not to use partials as they are in c#
> 
> 4) having explicit names for continuations is unwanted because naming is hard
> 
> 5) the ledger list is unnecessary as anyone on the same module will be able 
> to change it anyway - false feel of protection.
> 
> here are my thoughts on it.
> 
> 1) "generally in favour (e.g. to have ability of adding variables and 
> accessing privates at all)"
> -- great! thank you.
> 
> 2) "the name "continuation" is used for something else"
> -- thought the same. let it be "part" instead of continuation
> 
> 3) "why not to use partials as they are in c#"
> -- my belief here is that just because i made my type partial (for my own 
> reasons, e.g. as a result of splitting a single-file class into a multi-file) 
> it does not necessarily mean I want other developers of my team (on the same 
> module) to add continuations / parts to my class. in other words, while there 
> are the module boundaries (the building walls) i still want to see some 
> partitions between the rooms of that building to have some privacy.
> 
> 4) "having explicit names for continuations is unwanted because naming is 
> hard"
> -- every time I am adding extension now I want to label it somehow to 
> indicate it's purpose. if that extensions adds a protocol conformance (e.g. 
> "extension ViewController: UITableViewDataSource") the problem is not as 
> critical as the protocol (or the list of protocols) name itself can serve the 
> purpose of such an indication. if there is no such a protocol conformance 
> however i tend to add a "MARK: ThePurpose" or a comment ("extension 
> ViewController /* ThePurpose */) and as the comments are not checked and get 
> out of sync every time i do this i wish there was a a more explicit extension 
> label in the language for this purpose. maybe that's just me.
> 
> 5) "the ledger list is unnecessary as anyone on the same module will be able 
> to change it anyway - false feel of protection."
> -- to this i can give the same response as in (3). here is another example 
> that hopefully will clarify my point: we shall not really say that "private" 
> in swift is useless and "internal" shall be used instead of it just because 
> anyone in the same module can bypass it anyway: go to your class and change 
> the source from "private" to "internal" for their own benefits, so why bother 
> with private / fileprivate to begin with. so is true in regards to the 
> ledger: yes, it is true that anyone on the team working on the same module 
> has a physical ability to go to my class (the class who's sole maintainer and 
> "owner" is myself) and mess around it, changing it's ledger along the way, or 
> making it partial as in (3) or changing it's privates to internal, or adding 
> variables, etc. it's just they shouldn't, at least not talking to me first. 
> they won't be "behaving properly" if they do.
> 
> some additional thoughts. ledger works similar to the c++ class definition 
> itself, which lists all the members of the class, just on a less granular 
> scope: while in C++ you have to go there every time you want to add, say, a 
> private method, with parts you go change the ledger very infrequently, to add 
> a group or functionalities. another tangentially similar feature of C++ is 
> "friends". if you class have, say, 10 different extensions each implementing 
> a certain feature and you converted them to "parts" the ledger list will 
> contain 10 entries naming those features explicitly.
> 
> Mike
> 
> ps. by now i figured that discussing protection levels in swift is akin to 
> having a wonderful morning walk across a mine field
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

That makes sense.  I thought there may be a parsing trick involved with the way 
property accessors are designed.  

> On Nov 2, 2017, at 9:00 PM, Slava Pestov  wrote:
> 
> This is not possible in general, since we want the parser to be able to parse 
> code without having knowledge of declarations and their types (which might 
> come from other modules). Overloaded declarations complicate this further.
> 
> I agree that the existing property syntax already has this issue, which is 
> unfortunate, but we should not introduce features that make the problem worse.
> 
> Slava

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

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

[Slava Pestov via swift-evolution]

> On Nov 2, 2017, at 5:58 PM, Eric Summers  wrote:
> 
> A similar problem exists with property accessors.  Although you could call 
> those keywords, they will probably be extensible when behaviors are 
> introduced leading to a similar situation.  It can be worked around by making 
> the priority of argument labels higher then function calls within the curly 
> brackets.

This is not possible in general, since we want the parser to be able to parse 
code without having knowledge of declarations and their types (which might come 
from other modules). Overloaded declarations complicate this further.

I agree that the existing property syntax already has this issue, which is 
unfortunate, but we should not introduce features that make the problem worse.

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

Re: [swift-evolution] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

A similar problem exists with property accessors.  Although you could call 
those keywords, they will probably be extensible when behaviors are introduced 
leading to a similar situation.  It can be worked around by making the priority 
of argument labels higher then function calls within the curly brackets.

Eric

> On Nov 2, 2017, at 8:51 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution 
>> > wrote:
>> 
>> // A sugar similar to property accessors for multiple trailing closures:
>> foobar(a: 1, b: 2) {
>> completionBlock { x, y in
>> // ...
>> }
>> failureBlock { i, j in
>> // ...
>> }
>> }
> 
> This syntax is ambiguous. Are you passing in two trailing closures to 
> foobar(), or a single trailing closure, inside which you call two top-level 
> functions, completionBlock and failureBlock?
> 
> Slava
> 
> ___
> 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] Extending trailing closure sugar similar to property accessors

[Slava Pestov via swift-evolution]

> On Nov 2, 2017, at 4:04 PM, Eric Summers via swift-evolution 
>  wrote:
> 
> // A sugar similar to property accessors for multiple trailing closures:
> foobar(a: 1, b: 2) {
> completionBlock { x, y in
> // ...
> }
> failureBlock { i, j in
> // ...
> }
> }

This syntax is ambiguous. Are you passing in two trailing closures to foobar(), 
or a single trailing closure, inside which you call two top-level functions, 
completionBlock and failureBlock?

Slava

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

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Eric Summers via swift-evolution]

I think this makes more sense as part of a hygienic macro system.  These 
“hidden” parameters could be made available to standard functions using some 
sort of convention to exclude them from autocompletion.

Eric

> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> I like this idea as it's presented here, for the debugging/logging reasons 
> that you stated.
> 
> Should we tighten the shackles a little be to validate that *only* the 
> special #file/#line/#function directives can be permitted for these extra 
> parameters? I'm struggling to think of a case where we would want to allow 
> something else, since there's no way to provide the values for them in a 
> standard call.
> 
> 
> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
> > wrote:
> Hi SE,
> 
> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
> and #line where the operators are used to make debugging their use a lot 
> easier.
> 
> For example, given something the unwrap-or-die operator 
> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>  
> ),
>  you’d want to capture the #file and #line so you could pass it on to the 
> underlying call to fatalError().
> 
> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
> great to be able to capture the file and line where the operator is used so 
> you can quickly triage the bug in your code.
> 
> Unfortunately, Swift has the hard limit the the implementations of unary 
> operators may have one-and-only-one parameter, and that binary operators may 
> only have two parameters.
> 
> I’d like to propose a very minor change to Swift, whereby operator 
> implementations may have more than their one or two parameters, provided that 
> all subsequent parameters come with a default value. This would make it 
> trivial to add in #file, #line, #function, etc to your operator 
> implementations, which you can then capture for your own purposes.
> 
> An implementation of this change, with passing tests, can be found here: 
> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>  
> 
> 
> Dave
> ___
> 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

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

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Dave DeLong via swift-evolution]

While I agree that I can’t think of another use-case off the top of my head 
(curried operators, somehow? Maybe?), I also don’t necessarily see the benefit 
of restricting it.

As the implementation currently stands, we could add new keywords, like #module 
or #context (which would capture #file, #line, #function, #module, etc as a 
single type), without having to change the implementation of IsBinaryOperator() 
and IsUnaryOperator().

It’s also nice that if a legit use-case ever did come up, the language would 
support it out-of-the-box without requiring another change.

Dave

> On Nov 2, 2017, at 6:34 PM, Tony Allevato  wrote:
> 
> I like this idea as it's presented here, for the debugging/logging reasons 
> that you stated.
> 
> Should we tighten the shackles a little be to validate that *only* the 
> special #file/#line/#function directives can be permitted for these extra 
> parameters? I'm struggling to think of a case where we would want to allow 
> something else, since there's no way to provide the values for them in a 
> standard call.
> 
> 
> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
> > wrote:
> Hi SE,
> 
> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
> and #line where the operators are used to make debugging their use a lot 
> easier.
> 
> For example, given something the unwrap-or-die operator 
> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>  
> ),
>  you’d want to capture the #file and #line so you could pass it on to the 
> underlying call to fatalError().
> 
> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
> great to be able to capture the file and line where the operator is used so 
> you can quickly triage the bug in your code.
> 
> Unfortunately, Swift has the hard limit the the implementations of unary 
> operators may have one-and-only-one parameter, and that binary operators may 
> only have two parameters.
> 
> I’d like to propose a very minor change to Swift, whereby operator 
> implementations may have more than their one or two parameters, provided that 
> all subsequent parameters come with a default value. This would make it 
> trivial to add in #file, #line, #function, etc to your operator 
> implementations, which you can then capture for your own purposes.
> 
> An implementation of this change, with passing tests, can be found here: 
> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>  
> 
> 
> Dave
> ___
> 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] Proposal: Allow operators to have parameters with default values

[Tony Allevato via swift-evolution]

I like this idea as it's presented here, for the debugging/logging reasons
that you stated.

Should we tighten the shackles a little be to validate that *only* the
special #file/#line/#function directives can be permitted for these extra
parameters? I'm struggling to think of a case where we would want to allow
something else, since there's no way to provide the values for them in a
standard call.


On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi SE,
>
> As I’ve been using my own custom operators like “?!”, “!!”, or operators
> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file
> and #line where the operators are used to make debugging their use a lot
> easier.
>
> For example, given something the unwrap-or-die operator (
> https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md),
> you’d want to capture the #file and #line so you could pass it on to the
> underlying call to fatalError().
>
> Or, if you’re using a custom bind operator and something goes wrong, it’d
> be great to be able to capture the file and line where the operator is used
> so you can quickly triage the bug in your code.
>
> Unfortunately, Swift has the hard limit the the implementations of unary
> operators may have one-and-only-one parameter, and that binary operators
> may only have two parameters.
>
> I’d like to propose a very minor change to Swift, whereby operator
> implementations may have more than their one or two parameters, provided
> that all subsequent parameters come with a default value. This would make
> it trivial to add in #file, #line, #function, etc to your operator
> implementations, which you can then capture for your own purposes.
>
> An implementation of this change, with passing tests, can be found here:
> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>
> Dave
> ___
> 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

[swift-evolution] Revisiting SE-0132 Rationalizing Sequence end-operation names

[Brent Royal-Gordon via swift-evolution]

During the Swift 3 cycle, I proposed SE-0132, "Rationalizing Sequence 
end-operation names". It was rejected because it needed revision and there was 
no time to do so. Since then, part of the proposal—partial ranges and the 
`RangeExpression` slicing protocol—has been adopted in SE-0172, "One-sided 
Ranges". I''d like to reopen discussion of the rest of the proposal.

To refresh your memory, SE-0132 proposed systematically renaming a number of 
`Sequence` and `Collection` methods which operate on the beginning and end of a 
sequence. Many of these methods have names borrowed directly from functional 
programming; they use terminology in conflicting ways and don't follow our 
conventions for non-mutating method names. For example, consider the 
inconsistent and API Guideline-violating names of a few members which operate 
on the beginning of a sequence or collection:

first   dropFirst() removeFirst()
prefix(_:)  dropFirst(_:)   removeFirst(_:)
prefix(while:)  drop(while:)—

These members could be renamed to form consistent "families" where a given term 
always meant the same thing:

first   removingFirst() removeFirst()
prefix(_:)  removingPrefix(_:)  removePrefix(_:)
prefix(while:)  removingPrefix(while:)  —

The main question in my mind about this plan is source stability. Back during 
Swift 3, we broke compatibility willy-nilly, but today we're being a little 
more circumspect. I believe these names meet the criteria of being actively 
harmful—they are difficult to discover, so developers don't use these members 
even when they should, and many of them sound like mutating methods or are 
unclear about their purpose—but that still doesn't tell us how we should treat 
the old names.

Basically, when should we introduce the new names?

1. Swift 4.1 (or whatever pre-Swift 5 version the proposal ends up 
landing in)
2. Swift 4.n (the version of Swift 5's compatibility mode for Swift 4)
3. Swift 5

And when should we deprecate the old ones?

1. Swift 4.1
2. Swift 4.n
3. Swift 5
4. Swift 6
5. Never

I'm also open to discussion about whether this should be done at all, whether 
any additional methods should be included (or included methods should be left 
alone), whether the now-obsolete `prefix(from:)` `prefix(upTo:)`, and 
`prefix(through:)` methods should be left alone, deprecated, or removed, and 
whether this should be done in this proposal or a different one.

The original proposal, which lists all affected methods and explains the logic 
behind them, is available at 
.
 Keep in mind that the parts about ranges have already been incorporated into 
Swift in a revised form, so you can ignore them.

I'll get cracking on an implementation once we figure out what I should 
implement.

Thanks!

-- 
Brent Royal-Gordon  
Architechies
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Proposal: Allow operators to have parameters with default values

[Dave DeLong via swift-evolution]

Hi SE,

As I’ve been using my own custom operators like “?!”, “!!”, or operators 
provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file and 
#line where the operators are used to make debugging their use a lot easier.

For example, given something the unwrap-or-die operator 
(https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
 
),
 you’d want to capture the #file and #line so you could pass it on to the 
underlying call to fatalError().

Or, if you’re using a custom bind operator and something goes wrong, it’d be 
great to be able to capture the file and line where the operator is used so you 
can quickly triage the bug in your code.

Unfortunately, Swift has the hard limit the the implementations of unary 
operators may have one-and-only-one parameter, and that binary operators may 
only have two parameters.

I’d like to propose a very minor change to Swift, whereby operator 
implementations may have more than their one or two parameters, provided that 
all subsequent parameters come with a default value. This would make it trivial 
to add in #file, #line, #function, etc to your operator implementations, which 
you can then capture for your own purposes.

An implementation of this change, with passing tests, can be found here: 
https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
 


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

Re: [swift-evolution] Adding Result to the Standard Library

[Dave DeLong via swift-evolution]

> On Nov 2, 2017, at 6:19 PM, Dave DeLong  wrote:
> 
> 
> 
>> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> Proposing syntactic sugar for this at the same time would go a long way 
>> toward making me less reluctant to support it. As a type by itself, I don’t 
>> think it holds its weight in the standard library.
>> 
>> The question that I’d want to see answered is, is it possible to make it so 
>> that these two functions are identical for all intents and purposes?
>> 
>> func foo() throws -> Int
>> func foo() -> Result
> 
> I mentioned this equivalency during the async/await debate: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html
>  
> 
> 
> I think this would be a great addition.

Additionally, Erica had some thoughts around how to make unwrapping even 
easier, which includes support for Result:

https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f 


Dave

> 
>> 
>> Doing that at the call site is easy enough (the proposed implementation does 
>> much of that, but more could be done at the language level to remove the 
>> manual unwrapping), but I’m not sure how you reconcile the fact that, of 
>> those two declarations, an author *does* have to pick one to write.
>> 
>> One thing I can think of off the top of my head is forbid functions from 
>> returning Result<> but allow them to be created by assignment from a 
>> throwing function. That, however, seems like an arbitrary and just flat out 
>> bizarre limitation and I can’t really bring myself to support it.
>> 
>> I guess the problem I want to avoid is that, even if you sugar away all the 
>> differences between Result<> and throwing when it comes to *calling* these 
>> functions, there would still be two ways to declare essentially the same 
>> function, and the choice of which someone uses becomes arbitrary and 
>> meaningless.
>> 
>> On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution 
>> > wrote:
>> This is clearly a fine addition to the standard library; even Swift's Error 
>> Handling Rationale 
>> (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst 
>> )
>>  mentions such an addition
>> 
>> What separates standard library types from other types is that they have 
>> language level support, and the wrapping and unwrapping syntax here could 
>> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` 
>> incidentally--is so much less elegant in comparison to `?` and `!` for 
>> optionals (not that `Result` should use the exact such syntax for a distinct 
>> operation)). It would be a shame to transpose a third-party `Result` to the 
>> standard library without considering if any such tweaks would substantially 
>> improve ergonomics, interconversion with Optional and throws, etc.
>> 
>> 
>> 
>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution 
>> > wrote:
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in Alamofire to 
>> the standard library. I’d be happy to implement it (type and tests for 
>> free!) if someone could point me to the right place to do so. I’m not 
>> including it directly in this email, since it includes the full 
>> implementation and is therefore quite long. (Discourse, please!) 
>> 
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>  
>> 
>> 
>> 
>> Thanks, 
>> 
>> Jon Shier
>> 
>> 
>> 
>> ___
>> 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 
>> 
>> ___
>> 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] Adding Result to the Standard Library

[Dave DeLong via swift-evolution]

> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> Proposing syntactic sugar for this at the same time would go a long way 
> toward making me less reluctant to support it. As a type by itself, I don’t 
> think it holds its weight in the standard library.
> 
> The question that I’d want to see answered is, is it possible to make it so 
> that these two functions are identical for all intents and purposes?
> 
> func foo() throws -> Int
> func foo() -> Result

I mentioned this equivalency during the async/await debate: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039196.html
 


I think this would be a great addition.

Dave

> 
> Doing that at the call site is easy enough (the proposed implementation does 
> much of that, but more could be done at the language level to remove the 
> manual unwrapping), but I’m not sure how you reconcile the fact that, of 
> those two declarations, an author *does* have to pick one to write.
> 
> One thing I can think of off the top of my head is forbid functions from 
> returning Result<> but allow them to be created by assignment from a throwing 
> function. That, however, seems like an arbitrary and just flat out bizarre 
> limitation and I can’t really bring myself to support it.
> 
> I guess the problem I want to avoid is that, even if you sugar away all the 
> differences between Result<> and throwing when it comes to *calling* these 
> functions, there would still be two ways to declare essentially the same 
> function, and the choice of which someone uses becomes arbitrary and 
> meaningless.
> 
> On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution 
> > wrote:
> This is clearly a fine addition to the standard library; even Swift's Error 
> Handling Rationale 
> (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst 
> ) 
> mentions such an addition
> 
> What separates standard library types from other types is that they have 
> language level support, and the wrapping and unwrapping syntax here could 
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` 
> incidentally--is so much less elegant in comparison to `?` and `!` for 
> optionals (not that `Result` should use the exact such syntax for a distinct 
> operation)). It would be a shame to transpose a third-party `Result` to the 
> standard library without considering if any such tweaks would substantially 
> improve ergonomics, interconversion with Optional and throws, etc.
> 
> 
> 
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution 
> > wrote:
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> 
> ___
> 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 
> 
> ___
> 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] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

Proposing syntactic sugar for this at the same time would go a long way
toward making me less reluctant to support it. As a type by itself, I don’t
think it holds its weight in the standard library.

The question that I’d want to see answered is, is it possible to make it so
that these two functions are identical for all intents and purposes?

func foo() throws -> Int
func foo() -> Result

Doing that at the call site is easy enough (the proposed implementation
does much of that, but more could be done at the language level to remove
the manual unwrapping), but I’m not sure how you reconcile the fact that,
of those two declarations, an author *does* have to pick one to write.

One thing I can think of off the top of my head is forbid functions from
returning Result<> but allow them to be created by assignment from a
throwing function. That, however, seems like an arbitrary and just flat out
bizarre limitation and I can’t really bring myself to support it.

I guess the problem I want to avoid is that, even if you sugar away all the
differences between Result<> and throwing when it comes to *calling* these
functions, there would still be two ways to declare essentially the same
function, and the choice of which someone uses becomes arbitrary and
meaningless.

On Thu, Nov 2, 2017 at 5:02 PM Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This is clearly a fine addition to the standard library; even Swift's
> Error Handling Rationale (
> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst)
> mentions such an addition
>
> What separates standard library types from other types is that they have
> language level support, and the wrapping and unwrapping syntax here could
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
> incidentally--is so much less elegant in comparison to `?` and `!` for
> optionals (not that `Result` should use the exact such syntax for a
> distinct operation)). It would be a shame to transpose a third-party
> `Result` to the standard library without considering if any such tweaks
> would substantially improve ergonomics, interconversion with Optional and
> throws, etc.
>
>
>
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>>
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>>
>> ___
>> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

I’m certainly willing to adjust API to better match convention and 
guidelines. However, part of the proposal’s basis is the popularity of the 
Alamofire implementation (which is rather similar to the antitypical one in 
regards to additional API offered). Adding special syntax for it isn’t really 
something I want to do, as ever bit of that needs additional justification 
beyond the fact that’s it’s already in use.


Jon

> On Nov 2, 2017, at 8:01 PM, Xiaodi Wu  wrote:
> 
> This is clearly a fine addition to the standard library; even Swift's Error 
> Handling Rationale 
> (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst 
> ) 
> mentions such an addition
> 
> What separates standard library types from other types is that they have 
> language level support, and the wrapping and unwrapping syntax here could 
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` 
> incidentally--is so much less elegant in comparison to `?` and `!` for 
> optionals (not that `Result` should use the exact such syntax for a distinct 
> operation)). It would be a shame to transpose a third-party `Result` to the 
> standard library without considering if any such tweaks would substantially 
> improve ergonomics, interconversion with Optional and throws, etc.
> 
> 
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution 
> > wrote:
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> 
> ___
> 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] Adding Result to the Standard Library

[Xiaodi Wu via swift-evolution]

This is clearly a fine addition to the standard library; even Swift's Error
Handling Rationale (
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst)
mentions such an addition

What separates standard library types from other types is that they have
language level support, and the wrapping and unwrapping syntax here could
definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
incidentally--is so much less elegant in comparison to `?` and `!` for
optionals (not that `Result` should use the exact such syntax for a
distinct operation)). It would be a shame to transpose a third-party
`Result` to the standard library without considering if any such tweaks
would substantially improve ergonomics, interconversion with Optional and
throws, etc.


On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> Swift-Evolution:
> I’ve written a first draft of a proposal to add Result to the standard
> library by directly porting the Result type used in Alamofire to the
> standard library. I’d be happy to implement it (type and tests for free!)
> if someone could point me to the right place to do so. I’m not including it
> directly in this email, since it includes the full implementation and is
> therefore quite long. (Discourse, please!)
>
> https://github.com/jshier/swift-evolution/blob/master/
> proposals/0187-add-result-to-the-standard-library.md
>
>
> Thanks,
>
> Jon Shier
>
>
>
> ___
> 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

[swift-evolution] Extending trailing closure sugar similar to property accessors

[Eric Summers via swift-evolution]

I’d like to hear thoughts on extending trailing closure syntax to avoid long 
inline closures.  A significant benefit to adopting this sugar would be to 
clarify indentation style for long inline closures.  I apologize if this has 
been brought up before, but I couldn’t find anything searching the list.

There is a lot of discussion about hacking around the issues with inline 
closures.  Here are a few examples:
https://www.natashatherobot.com/swift-trailing-closure-syntax/
https://owensd.io/2015/02/20/handling-multiple-closure-parameters/
https://bugs.swift.org/browse/SR-1199
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html

I think a syntax similar to property accessors to allow multiple trailing 
closures could make these scenarios feel swifty.  Property accessors already 
have a "get" specialization that is similar to the current trailing closures 
syntax, so in theory this could be a backwards compatible extension. 

func foobar(a: Int, b: Int, completionBlock: ((Int, Int) -> Void), 
failureBlock: ((Int, Int) -> Void) {
// ...
}

// Current syntax:
foobar(a: 1, b: 2,
completionBlock: { x, y in
// ...
},
failureBlock: { i, j in
// ...
})

// A sugar similar to property accessors for multiple trailing closures:
foobar(a: 1, b: 2) {
completionBlock { x, y in
// ...
}
failureBlock { i, j in
// ...
}
}

Best,
Eric

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

Re: [swift-evolution] Abstract methods

[Lance Parker via swift-evolution]

How would a class partially implement a protocol? That’s a compile error.

> On Nov 2, 2017, at 2:30 PM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> If a class partially implemented a protocol, it also would not be 
> instantiatable, but a subclass can supply the missing method(s). Doesn’t the 
> compiler already handle that? How are abstract classes harder?
> 
> C. Keith Ray
> https://leanpub.com/wepntk  <- buy my book?
> http://agilesolutionspace.blogspot.com/ 
> 
> twitter: @ckeithray
> http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> 
> On Nov 2, 2017, at 2:22 PM, Slava Pestov  > wrote:
> 
>> Abstract methods and classes seem like they will introduce a fair amount of 
>> complexity in the type checker, particularly around metatypes and 
>> constructors, because now we have this new concept of a class that cannot be 
>> directly instantiated. I’m not sure the cost is worth the benefit.
>> 
>> Slava
>> 
>>> On Nov 2, 2017, at 12:45 PM, C. Keith Ray via swift-evolution 
>>> > wrote:
>>> 
>>> How many "subclass must override" assertions or comments in base class 
>>> methods do we need to see, to want to add "abstract" to the Swift language? 
>>> 5? 50? 500?
>>> 
>>> It's a not uncommon idiom in Objective-C.
>>> 
>>> I'm about to port a substantial amount of C++ code to swift, and compiler 
>>> help to enforce abstract classes would be very useful.
>>> 
>>> 
>>> --
>>> C. Keith Ray
>>> Senior Software Engineer / Trainer / Agile Coach
>>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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

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

Re: [swift-evolution] Adding Result to the Standard Library

[Benjamin G via swift-evolution]

Your point about async and the current work on that side of the language
seems convincing to me, however I'd say that Result could also be seing as
an improvement over Optional for handling what the
"ErrorHandlingRationale.rst" document calls "Simple Domain Errors" (so, not
requiring throw), but for which you also want to provide the reason for
returning nil (either for logging, or for any other reason).

ie : there seems to be an area not well covered by the language for
type-safe , self documenting, failable function calls. Throwing being a bit
"too much" and not self documenting enough (since you can't specify what
type of error the function is throwing), and optional is great if there's
only one possible reason for failing, but insufficient otherwise.

PS: once again, i haven't read the whole conversation at the time this list
discussed error handling, so sorry if all of this has already been
discussed..



On Thu, Nov 2, 2017 at 9:44 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Thu, Nov 2, 2017 at 12:41 PM Jon Shier  wrote:
>
>> This isn’t an argument against Result, it’s an argument against all error
>> encapsulation in Swift at all. Which is fine for your personal project, but
>> frankly I don’t see it as a bad thing as a language capability. Like any
>> other use of type-inference, the compiler guarantees you can’t use the
>> value of the function directly but must go through the Result value to get
>> it, which serves as the indication of there being an error there. Given the
>> usage of Result in the Swift community, I’m thinking your concerns aren’t
>> shared by the vast majority of Swift users. It’s entirely possible for
>> something to exist in the language and have it not be recommended as the
>> default implementation for something. For example, if/guard let are usually
>> recommended over map or flatMap’ing Optional, but the capability exists
>> because it’s very useful when the recommended pattern breaks down. Result
>> is no different.
>>
>
> Optional<>.flatMap isn't the same, because the *API being consumed* isn't
> what's changing—only how one chooses to consume it. It doesn't matter if
> you use if-let/guard-let or .flatMap, the type you're dealing with is still
> Optional<>. APIs that need something optional use Optional<>, period.
>
> Result<>, on the other hand, opens the door to bifurcating the API space
> into those that are throwing and those that are Result-returning, when
> they're trying to convey the same information. Sure, there are explicit
> functions to transform Result to throwing and vice-versa, but it's still
> something that forces certain decisions on API consumers. Code that
> consumes thrown errors vs. code that handles Result-return values will look
> different and inconsistent depending on which technique the API designer
> chose. That's not ideal.
>
> The proposal states the premise that Result<> is commonly desired and
> popular and is therefore a good fit for the standard library. Aside from
> its popularity, however, the only use case mentioned is asynchronous
> APIs—but the proposal doesn't mention any of the ongoing work in that area,
> and it doesn't offer any other examples of where Result<> would be clearly
> superior enough that warrant it being placed on equal ground with Swift's
> native error handling. It would be extremely helpful to flesh that out
> more—if there *are* strong use cases for why the language should offer
> users the ability to declare two different forms of error-propagating APIs,
> the proposal would be helped by showing them.
>
>
>
>>
>>
>> Jon
>>
>>
>>
>> On Nov 2, 2017, at 3:30 PM, Tony Allevato 
>> wrote:
>>
>>
>>
>> On Thu, Nov 2, 2017 at 12:21 PM Jon Shier  wrote:
>>
>>> The Result type I’ve outlined includes the functions necessary to
>>> translate between do try catch and Result. But I fundamentally disagree
>>> with your characterization of Swift’s error handling. At most, Swift
>>> strives to hide the line between normal functions and error throwing ones,
>>> but only until the developer needs access to those errors. If you’re using
>>> an API that takes throwing functions and handles the do / catch for you,
>>> then sure, you’ll never see the result of those functions as anything more
>>> than the values you get from those APIs But anyone writing their own try /
>>> catch statements is quite clearly going to see the result/error separation
>>> that Result encapsulates. In quite a few cases, passing an encapsulation
>>> around rather than having to either mark all functions as throwing in order
>>> to propagate an error, or constantly implementing try / catch, results is
>>> code that is far easier to read, write, and reason about it.
>>>
>>
>> I would think the opposite is true.
>>
>> let value = compute()
>>
>> Looking at this line of code, I have no idea whether I should expect to
>> handle errors or not. Does 

Re: [swift-evolution] Abstract methods

[C. Keith Ray via swift-evolution]

If a class partially implemented a protocol, it also would not be 
instantiatable, but a subclass can supply the missing method(s). Doesn’t the 
compiler already handle that? How are abstract classes harder?

C. Keith Ray
https://leanpub.com/wepntk <- buy my book?
http://agilesolutionspace.blogspot.com/
twitter: @ckeithray
http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf

> On Nov 2, 2017, at 2:22 PM, Slava Pestov  wrote:
> 
> Abstract methods and classes seem like they will introduce a fair amount of 
> complexity in the type checker, particularly around metatypes and 
> constructors, because now we have this new concept of a class that cannot be 
> directly instantiated. I’m not sure the cost is worth the benefit.
> 
> Slava
> 
>> On Nov 2, 2017, at 12:45 PM, C. Keith Ray via swift-evolution 
>>  wrote:
>> 
>> How many "subclass must override" assertions or comments in base class 
>> methods do we need to see, to want to add "abstract" to the Swift language? 
>> 5? 50? 500?
>> 
>> It's a not uncommon idiom in Objective-C.
>> 
>> I'm about to port a substantial amount of C++ code to swift, and compiler 
>> help to enforce abstract classes would be very useful.
>> 
>> 
>> --
>> C. Keith Ray
>> Senior Software Engineer / Trainer / Agile Coach
>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
>> 
>> 
>> 
>> ___
>> 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] Abstract methods

[Slava Pestov via swift-evolution]

Abstract methods and classes seem like they will introduce a fair amount of 
complexity in the type checker, particularly around metatypes and constructors, 
because now we have this new concept of a class that cannot be directly 
instantiated. I’m not sure the cost is worth the benefit.

Slava

> On Nov 2, 2017, at 12:45 PM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> How many "subclass must override" assertions or comments in base class 
> methods do we need to see, to want to add "abstract" to the Swift language? 
> 5? 50? 500?
> 
> It's a not uncommon idiom in Objective-C.
> 
> I'm about to port a substantial amount of C++ code to swift, and compiler 
> help to enforce abstract classes would be very useful.
> 
> 
> --
> C. Keith Ray
> Senior Software Engineer / Trainer / Agile Coach
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> 
> 
> 
> ___
> 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] Abstract methods

[Adam Kemp via swift-evolution]

Swift does still have inheritance, though. A language with inheritance and not 
abstract is frustrating to use, as evidenced by the hacks people resort to for 
Objective-C.

If we wanted to steer people away from inheritance then maybe we shouldn’t have 
supported it at all, but it’s a bit late for that.

> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution 
>  wrote:
> 
> Swift architectures use much less inheritance (and class types) in general 
> than equivalent c++ architectures. personally i have never been in a 
> situation where i didn’t need a pure abstract method that was better declared 
> as a protocol requirement.
> 
>> On Nov 2, 2017, at 2:45 PM, C. Keith Ray via swift-evolution 
>>  wrote:
>> 
>> How many "subclass must override" assertions or comments in base class 
>> methods do we need to see, to want to add "abstract" to the Swift language? 
>> 5? 50? 500?
>> 
>> It's a not uncommon idiom in Objective-C.
>> 
>> I'm about to port a substantial amount of C++ code to swift, and compiler 
>> help to enforce abstract classes would be very useful.
>> 
>> 
>> --
>> C. Keith Ray
>> Senior Software Engineer / Trainer / Agile Coach
>> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
>> 
>> 
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rocky Wei via swift-evolution]

Hi Chris and everyone else,

So PerfectlySoft made Perfect-Python months ago to help Swift import python 
objects and libraries. However, it may reduce the strong type checking. Any 
idea to avoid it?

https://github.com/PerfectlySoft/Perfect-Python 


You can also try Perfect-TensorFlow as well - the TensorFlow Swift Binding, 
which supports latest one -  TensorFlow 1.4.0 released today.

https://github.com/PerfectlySoft/Perfect-TensorFlow 


Rocky 

> On Oct 28, 2017, at 9:45 AM, Maxim Veksler via swift-evolution 
>  > wrote:
> > 
> > Hey Guys,
> > 
> > The big data and machine learning world is dominated by Python, Scala an R. 
> > 
> > I'm a Swifter by heart, but not so much by tools of trait. 
> 
> Hi Max,
> 
> I’m very interested in this topic, with a specific focus on Python.  It isn’t 
> the immediate thing on my priority list to deal with, but I hope that we get 
> to push on this.
> 
> In short, I think we should build a simple Swift/Python interop story.  This 
> sort of thing has be built numerous times for many languages (owing to 
> Python’s great support for embed-ability), including things like PyObjC, 
> boost.python, and many others.
> 
> In Swift, it is straightforward to make this example 
> (http://cs231n.github.io/python-numpy-tutorial/#numpy-arrays 
>  
>  >) look 
> something like this:
> 
>   let np = Python.import(“numpy”)   // Returns a value of type 
> Python.Object.
>   let a = np.array([1, 2, 3])
>   print(type(a))// Whether we want to support type(x) or use the 
> Swift equivalent would be up for discussion of course!
>   print(a.shape)
>   print(a[0], a[1], a[2])
>   a[0] = 5
>   print(a)
> 
>   let b = np.array([[1,2,3],[4,5,6]])
>   print(b.shape)
>   print(b[0, 0], b[0, 1], b[1, 0])
> 
> … which is to say, exactly identical to the Python version except that new 
> variables need to be declared with let/var.  This can be done by blessing 
> Python.Object (which is identical to “PyObject*” at the machine level) with 
> some special dynamic name lookup behavior:  Dot syntax turns into a call to 
> PyObject_GetAttrString, subscripts turn into PyObject_GetItem, calls turn 
> into PyObject_Call, etc.  ARC would be implemented with INCREF etc.
> 
> If we do this, the vast majority of the Python ecosystem should be directly 
> usable from within Swift code, and the only a few major syntactic differences 
> (e.g. ranges work differently).  We would add failable inits to the primitive 
> datatypes like Int/String/etc to convert Python.Object values into them, and 
> add the corresponding non-failable conversions from Python.Object to those 
> primitives.
> 
> Overall, I think it will provide a really nice experience, and allow us to 
> leverage the vast majority of the Python ecosystem directly in Swift code. 
> This project would also have much more narrow impact on the Swift compiler 
> than the ObjC importer (since it works completely differently).  For a first 
> cut, I don’t think we would have to worry about Swift classes subclassing 
> Python classes, for example.
> 
> -Chris
> 
> 
> 
> 
> 
> > 
> > I'd appreciate a constructive discussion on how that could be changed.
> > 
> > While R is a non goal for obvious reasons, i'd argue that since both Scala 
> > and Python are general purpose languages, taking them head to head might be 
> > a low hanging fruit.
> > 
> > To make the claim I'd like to reference to projects such as 
> > 
> >  - Hadoop, Spark, Hive are all huge eco-systems which are entirely JVM 
> > based.
> >  - Apache Parquet, a highly efficient column based storage format for big 
> > data analytics which was implemented in Java, and C++.
> >  - Apache Arrow, a physical memory spec that big data systems can use to 
> > allow zero transformations on data transferred between systems. Which (for 
> > obvious reasons) focused on JVM, to C interoperability.
> > 
> > Python's Buffer Protocol which ensures it's predominance (for the time 
> > being) as a prime candidate for data science related projects 
> > https://jeffknupp.com/blog/2017/09/15/python-is-the-fastest-growing-programming-language-due-to-a-feature-youve-never-heard-of/
> >  
> > 
> >  
> >  >  
> > >
> > 
> > While Swift's Memory Ownership 

Re: [swift-evolution] Abstract methods

[Taylor Swift via swift-evolution]

Swift architectures use much less inheritance (and class types) in general than 
equivalent c++ architectures. personally i have never been in a situation where 
i didn’t need a pure abstract method that was better declared as a protocol 
requirement.

> On Nov 2, 2017, at 2:45 PM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> How many "subclass must override" assertions or comments in base class 
> methods do we need to see, to want to add "abstract" to the Swift language? 
> 5? 50? 500?
> 
> It's a not uncommon idiom in Objective-C.
> 
> I'm about to port a substantial amount of C++ code to swift, and compiler 
> help to enforce abstract classes would be very useful.
> 
> 
> --
> C. Keith Ray
> Senior Software Engineer / Trainer / Agile Coach
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> 
> 
> 
> ___
> 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] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

On Thu, Nov 2, 2017 at 12:41 PM Jon Shier  wrote:

> This isn’t an argument against Result, it’s an argument against all error
> encapsulation in Swift at all. Which is fine for your personal project, but
> frankly I don’t see it as a bad thing as a language capability. Like any
> other use of type-inference, the compiler guarantees you can’t use the
> value of the function directly but must go through the Result value to get
> it, which serves as the indication of there being an error there. Given the
> usage of Result in the Swift community, I’m thinking your concerns aren’t
> shared by the vast majority of Swift users. It’s entirely possible for
> something to exist in the language and have it not be recommended as the
> default implementation for something. For example, if/guard let are usually
> recommended over map or flatMap’ing Optional, but the capability exists
> because it’s very useful when the recommended pattern breaks down. Result
> is no different.
>

Optional<>.flatMap isn't the same, because the *API being consumed* isn't
what's changing—only how one chooses to consume it. It doesn't matter if
you use if-let/guard-let or .flatMap, the type you're dealing with is still
Optional<>. APIs that need something optional use Optional<>, period.

Result<>, on the other hand, opens the door to bifurcating the API space
into those that are throwing and those that are Result-returning, when
they're trying to convey the same information. Sure, there are explicit
functions to transform Result to throwing and vice-versa, but it's still
something that forces certain decisions on API consumers. Code that
consumes thrown errors vs. code that handles Result-return values will look
different and inconsistent depending on which technique the API designer
chose. That's not ideal.

The proposal states the premise that Result<> is commonly desired and
popular and is therefore a good fit for the standard library. Aside from
its popularity, however, the only use case mentioned is asynchronous
APIs—but the proposal doesn't mention any of the ongoing work in that area,
and it doesn't offer any other examples of where Result<> would be clearly
superior enough that warrant it being placed on equal ground with Swift's
native error handling. It would be extremely helpful to flesh that out
more—if there *are* strong use cases for why the language should offer
users the ability to declare two different forms of error-propagating APIs,
the proposal would be helped by showing them.



>
>
> Jon
>
>
>
> On Nov 2, 2017, at 3:30 PM, Tony Allevato  wrote:
>
>
>
> On Thu, Nov 2, 2017 at 12:21 PM Jon Shier  wrote:
>
>> The Result type I’ve outlined includes the functions necessary to
>> translate between do try catch and Result. But I fundamentally disagree
>> with your characterization of Swift’s error handling. At most, Swift
>> strives to hide the line between normal functions and error throwing ones,
>> but only until the developer needs access to those errors. If you’re using
>> an API that takes throwing functions and handles the do / catch for you,
>> then sure, you’ll never see the result of those functions as anything more
>> than the values you get from those APIs But anyone writing their own try /
>> catch statements is quite clearly going to see the result/error separation
>> that Result encapsulates. In quite a few cases, passing an encapsulation
>> around rather than having to either mark all functions as throwing in order
>> to propagate an error, or constantly implementing try / catch, results is
>> code that is far easier to read, write, and reason about it.
>>
>
> I would think the opposite is true.
>
> let value = compute()
>
> Looking at this line of code, I have no idea whether I should expect to
> handle errors or not. Does "compute" return a Result<> or just the value I
> want? If we used throwing instead, it's obvious without any other context
> that an error can occur there:
>
> let value = try compute()
>
> That's another explicit design choice in Swift, that "try" marks
> expressions so it's very clear which expressions can throw, rather than
> just being a block that surrounds an arbitrarily long amount of code.
> Result<> provides none of that context.
>
>
>
>> Of course it’s not an absolute solution, which is why the ability to turn
>> a Result into a throwing function exists, but instead a complement to the
>> current error handling in Swift.
>>
>>
>> Jon
>>
>>
>> On Nov 2, 2017, at 3:11 PM, Tony Allevato 
>> wrote:
>>
>>
>>
>> On Thu, Nov 2, 2017 at 11:58 AM Jon Shier  wrote:
>>
>>> You would continue to be free to discourage the usage of Result for
>>> whatever you want. For the rest of us, Result isn’t intended to replace
>>> throws or do/catch, but provide a way to accomplish things in a much more
>>> compact and sometimes natural way. As with any API it could be used
>>> stupidly. 

[swift-evolution] Abstract methods

[C. Keith Ray via swift-evolution]

How many "subclass must override" assertions or comments in base class methods 
do we need to see, to want to add "abstract" to the Swift language? 5? 50? 500?

It's a not uncommon idiom in Objective-C.

I'm about to port a substantial amount of C++ code to swift, and compiler help 
to enforce abstract classes would be very useful.


--
C. Keith Ray
Senior Software Engineer / Trainer / Agile Coach
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf



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

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

This isn’t an argument against Result, it’s an argument against all 
error encapsulation in Swift at all. Which is fine for your personal project, 
but frankly I don’t see it as a bad thing as a language capability. Like any 
other use of type-inference, the compiler guarantees you can’t use the value of 
the function directly but must go through the Result value to get it, which 
serves as the indication of there being an error there. Given the usage of 
Result in the Swift community, I’m thinking your concerns aren’t shared by the 
vast majority of Swift users. It’s entirely possible for something to exist in 
the language and have it not be recommended as the default implementation for 
something. For example, if/guard let are usually recommended over map or 
flatMap’ing Optional, but the capability exists because it’s very useful when 
the recommended pattern breaks down. Result is no different.



Jon


> On Nov 2, 2017, at 3:30 PM, Tony Allevato  wrote:
> 
> 
> 
> On Thu, Nov 2, 2017 at 12:21 PM Jon Shier  > wrote:
>   The Result type I’ve outlined includes the functions necessary to 
> translate between do try catch and Result. But I fundamentally disagree with 
> your characterization of Swift’s error handling. At most, Swift strives to 
> hide the line between normal functions and error throwing ones, but only 
> until the developer needs access to those errors. If you’re using an API that 
> takes throwing functions and handles the do / catch for you, then sure, 
> you’ll never see the result of those functions as anything more than the 
> values you get from those APIs But anyone writing their own try / catch 
> statements is quite clearly going to see the result/error separation that 
> Result encapsulates. In quite a few cases, passing an encapsulation around 
> rather than having to either mark all functions as throwing in order to 
> propagate an error, or constantly implementing try / catch, results is code 
> that is far easier to read, write, and reason about it.
> 
> I would think the opposite is true.
> 
> let value = compute()
> 
> Looking at this line of code, I have no idea whether I should expect to 
> handle errors or not. Does "compute" return a Result<> or just the value I 
> want? If we used throwing instead, it's obvious without any other context 
> that an error can occur there:
> 
> let value = try compute()
> 
> That's another explicit design choice in Swift, that "try" marks expressions 
> so it's very clear which expressions can throw, rather than just being a 
> block that surrounds an arbitrarily long amount of code. Result<> provides 
> none of that context.
> 
>  
> Of course it’s not an absolute solution, which is why the ability to turn a 
> Result into a throwing function exists, but instead a complement to the 
> current error handling in Swift.
> 
> 
> Jon
> 
> 
>> On Nov 2, 2017, at 3:11 PM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Thu, Nov 2, 2017 at 11:58 AM Jon Shier > > wrote:
>>  You would continue to be free to discourage the usage of Result for 
>> whatever you want. For the rest of us, Result isn’t intended to replace 
>> throws or do/catch, but provide a way to accomplish things in a much more 
>> compact and sometimes natural way. As with any API it could be used 
>> stupidly. But frankly, what developers what to do to wrap their errors is up 
>> to them.
>> 
>> And it still is, with the Result implementations that are available to 
>> third-parties today.
>> 
>> My concerns regarding Result aren't about my personal discouragement of its 
>> use, but the *reasons* why I discourage its use. The Swift language very 
>> deliberately draws a line between result outcomes that are return values and 
>> error outcomes that are thrown, and it implements not only standard library 
>> types but also language syntactic sugar to support those.
>> 
>> If someone wants to depend on a third-party Result<> to conflate successful 
>> outcomes and error outcomes in their own code, that's absolutely their 
>> right. But entry into the standard library has a much higher bar, and what 
>> we're talking about here is adding a feature that now would give users two 
>> disparate and incompatible ways (without explicit transformations, or other 
>> syntactic sugar) of handling errors. That makes me uneasy from the point of 
>> view of both an API designer and consumer, and just restating that it's a 
>> common pattern and people want it doesn't address those concerns.
>> 
>> 
>>  
>> Adding Result is just a way of blessing a result/error representation, since 
>> it has become a rather common pattern. If you’ve looked at the 
>> implementation I showed, you’ll see that there’s far more functionality than 
>> just a Result type, including API for converting back and 

Re: [swift-evolution] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

On Thu, Nov 2, 2017 at 12:21 PM Jon Shier  wrote:

> The Result type I’ve outlined includes the functions necessary to
> translate between do try catch and Result. But I fundamentally disagree
> with your characterization of Swift’s error handling. At most, Swift
> strives to hide the line between normal functions and error throwing ones,
> but only until the developer needs access to those errors. If you’re using
> an API that takes throwing functions and handles the do / catch for you,
> then sure, you’ll never see the result of those functions as anything more
> than the values you get from those APIs But anyone writing their own try /
> catch statements is quite clearly going to see the result/error separation
> that Result encapsulates. In quite a few cases, passing an encapsulation
> around rather than having to either mark all functions as throwing in order
> to propagate an error, or constantly implementing try / catch, results is
> code that is far easier to read, write, and reason about it.
>

I would think the opposite is true.

let value = compute()

Looking at this line of code, I have no idea whether I should expect to
handle errors or not. Does "compute" return a Result<> or just the value I
want? If we used throwing instead, it's obvious without any other context
that an error can occur there:

let value = try compute()

That's another explicit design choice in Swift, that "try" marks
expressions so it's very clear which expressions can throw, rather than
just being a block that surrounds an arbitrarily long amount of code.
Result<> provides none of that context.



> Of course it’s not an absolute solution, which is why the ability to turn
> a Result into a throwing function exists, but instead a complement to the
> current error handling in Swift.
>
>
> Jon
>
>
> On Nov 2, 2017, at 3:11 PM, Tony Allevato  wrote:
>
>
>
> On Thu, Nov 2, 2017 at 11:58 AM Jon Shier  wrote:
>
>> You would continue to be free to discourage the usage of Result for
>> whatever you want. For the rest of us, Result isn’t intended to replace
>> throws or do/catch, but provide a way to accomplish things in a much more
>> compact and sometimes natural way. As with any API it could be used
>> stupidly. But frankly, what developers what to do to wrap their errors is
>> up to them.
>>
>
> And it still is, with the Result implementations that are available to
> third-parties today.
>
> My concerns regarding Result aren't about my personal discouragement of
> its use, but the *reasons* why I discourage its use. The Swift language
> very deliberately draws a line between result outcomes that are return
> values and error outcomes that are thrown, and it implements not only
> standard library types but also language syntactic sugar to support those.
>
> If someone wants to depend on a third-party Result<> to conflate
> successful outcomes and error outcomes in their own code, that's absolutely
> their right. But entry into the standard library has a much higher bar, and
> what we're talking about here is adding a feature that now would give users
> two disparate and incompatible ways (without explicit transformations, or
> other syntactic sugar) of handling errors. That makes me uneasy from the
> point of view of both an API designer and consumer, and just restating that
> it's a common pattern and people want it doesn't address those concerns.
>
>
>
>
>> Adding Result is just a way of blessing a result/error representation,
>> since it has become a rather common pattern. If you’ve looked at the
>> implementation I showed, you’ll see that there’s far more functionality
>> than just a Result type, including API for converting back and forth from
>> throwing functions, as well as functional transforms. Result is a
>> complement to try do catch, not a replacement.
>>
>>
>>
>> Jon
>>
>>
>>
>>
>> On Nov 2, 2017, at 2:48 PM, Tony Allevato 
>> wrote:
>>
>>
>>
>> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  wrote:
>>
>>> That’s been an argument against Result for 2 years now. The usefulness
>>> of the type, even outside of whatever asynchronous language support the
>>> core team comes up with, perhaps this year, perhaps next year, is still
>>> very high. Even as something that just wraps throwing functions, or
>>> otherwise exists as a local, synchronous value, it’s still very useful as
>>> way to encapsulate the value/error pattern.
>>>
>>
>> This is one of the parts that concerns me, actually. The beauty of
>> Swift's error design is that function results denote expected/successful
>> outcomes and thrown errors denote unexpected/erroneous outcomes. Since they
>> are different, each is handled through its own language constructs, and
>> since the language itself supports it (rather than being entirely
>> type-based), you don't have the proliferation of unwrapping boilerplate
>> that you have with Result<>.
>>
>> In our 

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

The Result type I’ve outlined includes the functions necessary to 
translate between do try catch and Result. But I fundamentally disagree with 
your characterization of Swift’s error handling. At most, Swift strives to hide 
the line between normal functions and error throwing ones, but only until the 
developer needs access to those errors. If you’re using an API that takes 
throwing functions and handles the do / catch for you, then sure, you’ll never 
see the result of those functions as anything more than the values you get from 
those APIs But anyone writing their own try / catch statements is quite clearly 
going to see the result/error separation that Result encapsulates. In quite a 
few cases, passing an encapsulation around rather than having to either mark 
all functions as throwing in order to propagate an error, or constantly 
implementing try / catch, results is code that is far easier to read, write, 
and reason about it. Of course it’s not an absolute solution, which is why the 
ability to turn a Result into a throwing function exists, but instead a 
complement to the current error handling in Swift.


Jon

> On Nov 2, 2017, at 3:11 PM, Tony Allevato  wrote:
> 
> 
> 
> On Thu, Nov 2, 2017 at 11:58 AM Jon Shier  > wrote:
>   You would continue to be free to discourage the usage of Result for 
> whatever you want. For the rest of us, Result isn’t intended to replace 
> throws or do/catch, but provide a way to accomplish things in a much more 
> compact and sometimes natural way. As with any API it could be used stupidly. 
> But frankly, what developers what to do to wrap their errors is up to them.
> 
> And it still is, with the Result implementations that are available to 
> third-parties today.
> 
> My concerns regarding Result aren't about my personal discouragement of its 
> use, but the *reasons* why I discourage its use. The Swift language very 
> deliberately draws a line between result outcomes that are return values and 
> error outcomes that are thrown, and it implements not only standard library 
> types but also language syntactic sugar to support those.
> 
> If someone wants to depend on a third-party Result<> to conflate successful 
> outcomes and error outcomes in their own code, that's absolutely their right. 
> But entry into the standard library has a much higher bar, and what we're 
> talking about here is adding a feature that now would give users two 
> disparate and incompatible ways (without explicit transformations, or other 
> syntactic sugar) of handling errors. That makes me uneasy from the point of 
> view of both an API designer and consumer, and just restating that it's a 
> common pattern and people want it doesn't address those concerns.
> 
> 
>  
> Adding Result is just a way of blessing a result/error representation, since 
> it has become a rather common pattern. If you’ve looked at the implementation 
> I showed, you’ll see that there’s far more functionality than just a Result 
> type, including API for converting back and forth from throwing functions, as 
> well as functional transforms. Result is a complement to try do catch, not a 
> replacement.
> 
> 
> 
> Jon
> 
>   
>   
> 
>> On Nov 2, 2017, at 2:48 PM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier > > wrote:
>>  That’s been an argument against Result for 2 years now. The usefulness 
>> of the type, even outside of whatever asynchronous language support the core 
>> team comes up with, perhaps this year, perhaps next year, is still very 
>> high. Even as something that just wraps throwing functions, or otherwise 
>> exists as a local, synchronous value, it’s still very useful as way to 
>> encapsulate the value/error pattern.
>> 
>> This is one of the parts that concerns me, actually. The beauty of Swift's 
>> error design is that function results denote expected/successful outcomes 
>> and thrown errors denote unexpected/erroneous outcomes. Since they are 
>> different, each is handled through its own language constructs, and since 
>> the language itself supports it (rather than being entirely type-based), you 
>> don't have the proliferation of unwrapping boilerplate that you have with 
>> Result<>.
>> 
>> In our own code bases, I actively discourage the use of Result<> in that 
>> way, because it tries to cram both of those concepts into the 
>> expected/successful outcomes slot in the language. For asynchronous APIs 
>> that's somewhat unavoidable today, but if that's going to change, I'd rather 
>> the language focus on a way that's consistent with other error handling 
>> already present in Swift.
>> 
>> Adding an API to the standard library is the core team saying "this is 
>> blessed as something around which we support APIs being designed." IMO, I'd 
>> 

Re: [swift-evolution] Adding Result to the Standard Library

[Matthew Johnson via swift-evolution]

I have been writing code in a style that uses explicit effect handling lately.  
In this style of code, a request describing an async task is returned from a 
function and later interpreted by a library.  When the task completes the 
library passes the result to completion handler that is part of the task 
description (which produces subsequent effects to interpret).  

It isn’t possible to express the completion handlers attached to task 
descriptions as an async call.  The function needs to return the task 
description immediately.  For this reason, I believe it will be necessary to 
continue using a Result type in code written in this style even after async / 
await is introduced.

> On Nov 2, 2017, at 1:53 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> With the upcoming async-await constructs supporting do-try-catch natively, 
> what would the use-case for an explicit Result type be?
> 
> Dan
> 
>> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>> > wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in Alamofire to 
>> the standard library. I’d be happy to implement it (type and tests for 
>> free!) if someone could point me to the right place to do so. I’m not 
>> including it directly in this email, since it includes the full 
>> implementation and is therefore quite long. (Discourse, please!) 
>> 
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>  
>> 
>> 
>> 
>> Thanks, 
>> 
>> Jon Shier
>> 
>> 
>> ___
>> 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

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

Re: [swift-evolution] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

On Thu, Nov 2, 2017 at 11:58 AM Jon Shier  wrote:

> You would continue to be free to discourage the usage of Result for
> whatever you want. For the rest of us, Result isn’t intended to replace
> throws or do/catch, but provide a way to accomplish things in a much more
> compact and sometimes natural way. As with any API it could be used
> stupidly. But frankly, what developers what to do to wrap their errors is
> up to them.
>

And it still is, with the Result implementations that are available to
third-parties today.

My concerns regarding Result aren't about my personal discouragement of its
use, but the *reasons* why I discourage its use. The Swift language very
deliberately draws a line between result outcomes that are return values
and error outcomes that are thrown, and it implements not only standard
library types but also language syntactic sugar to support those.

If someone wants to depend on a third-party Result<> to conflate successful
outcomes and error outcomes in their own code, that's absolutely their
right. But entry into the standard library has a much higher bar, and what
we're talking about here is adding a feature that now would give users two
disparate and incompatible ways (without explicit transformations, or other
syntactic sugar) of handling errors. That makes me uneasy from the point of
view of both an API designer and consumer, and just restating that it's a
common pattern and people want it doesn't address those concerns.




> Adding Result is just a way of blessing a result/error representation,
> since it has become a rather common pattern. If you’ve looked at the
> implementation I showed, you’ll see that there’s far more functionality
> than just a Result type, including API for converting back and forth from
> throwing functions, as well as functional transforms. Result is a
> complement to try do catch, not a replacement.
>
>
>
> Jon
>
>
>
>
> On Nov 2, 2017, at 2:48 PM, Tony Allevato  wrote:
>
>
>
> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  wrote:
>
>> That’s been an argument against Result for 2 years now. The usefulness of
>> the type, even outside of whatever asynchronous language support the core
>> team comes up with, perhaps this year, perhaps next year, is still very
>> high. Even as something that just wraps throwing functions, or otherwise
>> exists as a local, synchronous value, it’s still very useful as way to
>> encapsulate the value/error pattern.
>>
>
> This is one of the parts that concerns me, actually. The beauty of Swift's
> error design is that function results denote expected/successful outcomes
> and thrown errors denote unexpected/erroneous outcomes. Since they are
> different, each is handled through its own language constructs, and since
> the language itself supports it (rather than being entirely type-based),
> you don't have the proliferation of unwrapping boilerplate that you have
> with Result<>.
>
> In our own code bases, I actively discourage the use of Result<> in that
> way, because it tries to cram both of those concepts into the
> expected/successful outcomes slot in the language. For asynchronous APIs
> that's somewhat unavoidable today, but if that's going to change, I'd
> rather the language focus on a way that's consistent with other error
> handling already present in Swift.
>
> Adding an API to the standard library is the core team saying "this is
> blessed as something around which we support APIs being designed." IMO, I'd
> prefer it if the language did *not* bless two disparate ways of
> communicating error outcomes but rather converged on one.
>
> IMO, "things aren't happening fast enough" isn't great motivation for
> putting something permanently into the standard library or the language
> without considering the context of other things going on around it. If
> you're going to propose something that overlaps with asynchronous APIs, it
> only helps your case if you can discuss how it can integrate—rather than
> collide—with those efforts.
>
>
>
>
>> That pattern will likely never go away. Additionally, having the Result
>> type in the standard library removes a source of conflict between all other
>> Result implementations, which are becoming more common.
>>
>>
>> On Nov 2, 2017, at 2:26 PM, Tony Allevato 
>> wrote:
>>
>> Given that the Swift team is currently working on laying the groundwork
>> for asynchronous APIs using an async/await model, which would presumably
>> tie the throwing cases more naturally into the language than what is
>> possible using completion-closures today, are we sure that this wouldn't
>> duplicate any efforts there or be made obsolete through other means?
>>
>> In other words, while Result<> can be a very useful foundational
>> component on its own, I think any proposal for it can't be made in
>> isolation, but very much needs to consider other asynchronous work going on
>> in the language.
>>
>>
>> On Thu, 

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

This is largely unanswerable until that feature is actually designed. 
However, I can imaging wrapping an async-await in a Result to be easily passed 
around or transformed. Plus all of the usual non-asynchronous uses of Result in 
the first place.



Jon


> On Nov 2, 2017, at 2:52 PM, Dan Stenmark  wrote:
> 
> With the upcoming async-await constructs supporting do-try-catch natively, 
> what would the use-case for an explicit Result type be?
> 
> Dan
> 
>> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>> > wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in Alamofire to 
>> the standard library. I’d be happy to implement it (type and tests for 
>> free!) if someone could point me to the right place to do so. I’m not 
>> including it directly in this email, since it includes the full 
>> implementation and is therefore quite long. (Discourse, please!) 
>> 
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>  
>> 
>> 
>> 
>> Thanks, 
>> 
>> Jon Shier
>> 
>> 
>> ___
>> 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] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

You would continue to be free to discourage the usage of Result for 
whatever you want. For the rest of us, Result isn’t intended to replace throws 
or do/catch, but provide a way to accomplish things in a much more compact and 
sometimes natural way. As with any API it could be used stupidly. But frankly, 
what developers what to do to wrap their errors is up to them. Adding Result is 
just a way of blessing a result/error representation, since it has become a 
rather common pattern. If you’ve looked at the implementation I showed, you’ll 
see that there’s far more functionality than just a Result type, including API 
for converting back and forth from throwing functions, as well as functional 
transforms. Result is a complement to try do catch, not a replacement.



Jon



> On Nov 2, 2017, at 2:48 PM, Tony Allevato  wrote:
> 
> 
> 
> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  > wrote:
>   That’s been an argument against Result for 2 years now. The usefulness 
> of the type, even outside of whatever asynchronous language support the core 
> team comes up with, perhaps this year, perhaps next year, is still very high. 
> Even as something that just wraps throwing functions, or otherwise exists as 
> a local, synchronous value, it’s still very useful as way to encapsulate the 
> value/error pattern.
> 
> This is one of the parts that concerns me, actually. The beauty of Swift's 
> error design is that function results denote expected/successful outcomes and 
> thrown errors denote unexpected/erroneous outcomes. Since they are different, 
> each is handled through its own language constructs, and since the language 
> itself supports it (rather than being entirely type-based), you don't have 
> the proliferation of unwrapping boilerplate that you have with Result<>.
> 
> In our own code bases, I actively discourage the use of Result<> in that way, 
> because it tries to cram both of those concepts into the expected/successful 
> outcomes slot in the language. For asynchronous APIs that's somewhat 
> unavoidable today, but if that's going to change, I'd rather the language 
> focus on a way that's consistent with other error handling already present in 
> Swift.
> 
> Adding an API to the standard library is the core team saying "this is 
> blessed as something around which we support APIs being designed." IMO, I'd 
> prefer it if the language did *not* bless two disparate ways of communicating 
> error outcomes but rather converged on one.
> 
> IMO, "things aren't happening fast enough" isn't great motivation for putting 
> something permanently into the standard library or the language without 
> considering the context of other things going on around it. If you're going 
> to propose something that overlaps with asynchronous APIs, it only helps your 
> case if you can discuss how it can integrate—rather than collide—with those 
> efforts.
> 
> 
>  
> That pattern will likely never go away. Additionally, having the Result type 
> in the standard library removes a source of conflict between all other Result 
> implementations, which are becoming more common.
> 
> 
>> On Nov 2, 2017, at 2:26 PM, Tony Allevato > > wrote:
>> 
>> Given that the Swift team is currently working on laying the groundwork for 
>> asynchronous APIs using an async/await model, which would presumably tie the 
>> throwing cases more naturally into the language than what is possible using 
>> completion-closures today, are we sure that this wouldn't duplicate any 
>> efforts there or be made obsolete through other means?
>> 
>> In other words, while Result<> can be a very useful foundational component 
>> on its own, I think any proposal for it can't be made in isolation, but very 
>> much needs to consider other asynchronous work going on in the language.
>> 
>> 
>> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution 
>> > wrote:
>> You don’t lose it, it’s just behind `Error`. You can cast out whatever 
>> strong error type you need without having to bind an entire type to it 
>> generically. If getting a common error type out happens a lot, I usually add 
>> a convenience property to `Error` to do the cast for me. Plus, having to 
>> expose an entire new error wrapper is just a non starter for me and doesn’t 
>> seem necessary, given how Result is currently used in the community.
>> 
>> 
>> Jon
>> 
>> 
>>> On Nov 2, 2017, at 2:12 PM, Dave DeLong >> > wrote:
>>> 
>>> I think I’d personally rather see this done with a generic error as well, 
>>> like:
>>> 
>>> enum GenericResult {
>>> case success(T)
>>> case failure(E)
>>> }
>>> 
>>> And a typealias:
>>> 
>>> typealias Result = GenericResult
>>> 
>>> This would require an 

Re: [swift-evolution] Adding Result to the Standard Library

[Goffredo Marocchi via swift-evolution]

Key words: “if that is going to change” and I would add “even if it changes 
would all async use cases map to the new paradigm?”. I understand your 
concerns, but I am also wary of promised silver bullet solutions that promise 
or aim to take care of all use cases...

Sent from my iPhone

> On 2 Nov 2017, at 18:48, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
>> On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  wrote:
>>  That’s been an argument against Result for 2 years now. The usefulness 
>> of the type, even outside of whatever asynchronous language support the core 
>> team comes up with, perhaps this year, perhaps next year, is still very 
>> high. Even as something that just wraps throwing functions, or otherwise 
>> exists as a local, synchronous value, it’s still very useful as way to 
>> encapsulate the value/error pattern.
> 
> This is one of the parts that concerns me, actually. The beauty of Swift's 
> error design is that function results denote expected/successful outcomes and 
> thrown errors denote unexpected/erroneous outcomes. Since they are different, 
> each is handled through its own language constructs, and since the language 
> itself supports it (rather than being entirely type-based), you don't have 
> the proliferation of unwrapping boilerplate that you have with Result<>.
> 
> In our own code bases, I actively discourage the use of Result<> in that way, 
> because it tries to cram both of those concepts into the expected/successful 
> outcomes slot in the language. For asynchronous APIs that's somewhat 
> unavoidable today, but if that's going to change, I'd rather the language 
> focus on a way that's consistent with other error handling already present in 
> Swift.
> 
> Adding an API to the standard library is the core team saying "this is 
> blessed as something around which we support APIs being designed." IMO, I'd 
> prefer it if the language did *not* bless two disparate ways of communicating 
> error outcomes but rather converged on one.
> 
> IMO, "things aren't happening fast enough" isn't great motivation for putting 
> something permanently into the standard library or the language without 
> considering the context of other things going on around it. If you're going 
> to propose something that overlaps with asynchronous APIs, it only helps your 
> case if you can discuss how it can integrate—rather than collide—with those 
> efforts.
> 
> 
>  
>> That pattern will likely never go away. Additionally, having the Result type 
>> in the standard library removes a source of conflict between all other 
>> Result implementations, which are becoming more common.
>> 
>> 
>>> On Nov 2, 2017, at 2:26 PM, Tony Allevato  wrote:
>>> 
>>> Given that the Swift team is currently working on laying the groundwork for 
>>> asynchronous APIs using an async/await model, which would presumably tie 
>>> the throwing cases more naturally into the language than what is possible 
>>> using completion-closures today, are we sure that this wouldn't duplicate 
>>> any efforts there or be made obsolete through other means?
>>> 
>>> In other words, while Result<> can be a very useful foundational component 
>>> on its own, I think any proposal for it can't be made in isolation, but 
>>> very much needs to consider other asynchronous work going on in the 
>>> language.
>>> 
>>> 
 On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution 
  wrote:
 You don’t lose it, it’s just behind `Error`. You can cast out whatever 
 strong error type you need without having to bind an entire type to it 
 generically. If getting a common error type out happens a lot, I usually 
 add a convenience property to `Error` to do the cast for me. Plus, having 
 to expose an entire new error wrapper is just a non starter for me and 
 doesn’t seem necessary, given how Result is currently used in the 
 community.
 
 
 Jon
 
 
> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
> 
> I think I’d personally rather see this done with a generic error as well, 
> like:
> 
> enum GenericResult {
>   case success(T)
>   case failure(E)
> }
> 
> And a typealias:
> 
> typealias Result = GenericResult
> 
> This would require an “AnyError” type to type-erase a specific Error, but 
> I’ve come across many situations where a strongly-typed error is 
> incredibly useful, and I’d be reluctant to see that thrown away.
> 
> Dave
> 
>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
>>  wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in 
>> Alamofire to the standard library. I’d be 

Re: [swift-evolution] Adding Result to the Standard Library

[Dan Stenmark via swift-evolution]

With the upcoming async-await constructs supporting do-try-catch natively, what 
would the use-case for an explicit Result type be?

Dan

> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>  wrote:
> 
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> ___
> 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] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

On Thu, Nov 2, 2017 at 11:32 AM Jon Shier  wrote:

> That’s been an argument against Result for 2 years now. The usefulness of
> the type, even outside of whatever asynchronous language support the core
> team comes up with, perhaps this year, perhaps next year, is still very
> high. Even as something that just wraps throwing functions, or otherwise
> exists as a local, synchronous value, it’s still very useful as way to
> encapsulate the value/error pattern.
>

This is one of the parts that concerns me, actually. The beauty of Swift's
error design is that function results denote expected/successful outcomes
and thrown errors denote unexpected/erroneous outcomes. Since they are
different, each is handled through its own language constructs, and since
the language itself supports it (rather than being entirely type-based),
you don't have the proliferation of unwrapping boilerplate that you have
with Result<>.

In our own code bases, I actively discourage the use of Result<> in that
way, because it tries to cram both of those concepts into the
expected/successful outcomes slot in the language. For asynchronous APIs
that's somewhat unavoidable today, but if that's going to change, I'd
rather the language focus on a way that's consistent with other error
handling already present in Swift.

Adding an API to the standard library is the core team saying "this is
blessed as something around which we support APIs being designed." IMO, I'd
prefer it if the language did *not* bless two disparate ways of
communicating error outcomes but rather converged on one.

IMO, "things aren't happening fast enough" isn't great motivation for
putting something permanently into the standard library or the language
without considering the context of other things going on around it. If
you're going to propose something that overlaps with asynchronous APIs, it
only helps your case if you can discuss how it can integrate—rather than
collide—with those efforts.




> That pattern will likely never go away. Additionally, having the Result
> type in the standard library removes a source of conflict between all other
> Result implementations, which are becoming more common.
>
>
> On Nov 2, 2017, at 2:26 PM, Tony Allevato  wrote:
>
> Given that the Swift team is currently working on laying the groundwork
> for asynchronous APIs using an async/await model, which would presumably
> tie the throwing cases more naturally into the language than what is
> possible using completion-closures today, are we sure that this wouldn't
> duplicate any efforts there or be made obsolete through other means?
>
> In other words, while Result<> can be a very useful foundational component
> on its own, I think any proposal for it can't be made in isolation, but
> very much needs to consider other asynchronous work going on in the
> language.
>
>
> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> You don’t lose it, it’s just behind `Error`. You can cast out whatever
>> strong error type you need without having to bind an entire type to it
>> generically. If getting a common error type out happens a lot, I usually
>> add a convenience property to `Error` to do the cast for me. Plus, having
>> to expose an entire new error wrapper is just a non starter for me and
>> doesn’t seem necessary, given how Result is currently used in the community.
>>
>>
>> Jon
>>
>>
>> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
>>
>> I think I’d personally rather see this done with a generic error as well,
>> like:
>>
>> enum GenericResult {
>> case success(T)
>> case failure(E)
>> }
>>
>> And a typealias:
>>
>> typealias Result = GenericResult
>>
>> This would require an “AnyError” type to type-erase a specific Error, but
>> I’ve come across many situations where a strongly-typed error is *incredibly
>> *useful, and I’d be reluctant to see that thrown away.
>>
>> Dave
>>
>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>>
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> 

Re: [swift-evolution] Adding Result to the Standard Library

[T.J. Usiyan via swift-evolution]

+1 from me… for what it's worth. The value, in my opinion, is that we won't
each have to add result. I would prefer Either but I will take
Result.

On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Nov 2, 2017, at 12:32 PM, Jon Shier  wrote:
>
> That’s been an argument against Result for 2 years now. The usefulness of
> the type, even outside of whatever asynchronous language support the core
> team comes up with, perhaps this year, perhaps next year, is still very
> high. Even as something that just wraps throwing functions, or otherwise
> exists as a local, synchronous value, it’s still very useful as way to
> encapsulate the value/error pattern. That pattern will likely never go
> away. Additionally, having the Result type in the standard library removes
> a source of conflict between all other Result implementations, which are
> becoming more common.
>
>
>  
>
> There’s a lot of stuff I’m tired of implementing myself while waiting for
> the the core team “to lay the ground for”. Result is up there near the top
> of my list too.
>
> Dave
>
>
>
> On Nov 2, 2017, at 2:26 PM, Tony Allevato  wrote:
>
> Given that the Swift team is currently working on laying the groundwork
> for asynchronous APIs using an async/await model, which would presumably
> tie the throwing cases more naturally into the language than what is
> possible using completion-closures today, are we sure that this wouldn't
> duplicate any efforts there or be made obsolete through other means?
>
> In other words, while Result<> can be a very useful foundational component
> on its own, I think any proposal for it can't be made in isolation, but
> very much needs to consider other asynchronous work going on in the
> language.
>
>
> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> You don’t lose it, it’s just behind `Error`. You can cast out whatever
>> strong error type you need without having to bind an entire type to it
>> generically. If getting a common error type out happens a lot, I usually
>> add a convenience property to `Error` to do the cast for me. Plus, having
>> to expose an entire new error wrapper is just a non starter for me and
>> doesn’t seem necessary, given how Result is currently used in the community.
>>
>>
>> Jon
>>
>>
>> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
>>
>> I think I’d personally rather see this done with a generic error as well,
>> like:
>>
>> enum GenericResult {
>> case success(T)
>> case failure(E)
>> }
>>
>> And a typealias:
>>
>> typealias Result = GenericResult
>>
>> This would require an “AnyError” type to type-erase a specific Error, but
>> I’ve come across many situations where a strongly-typed error is *incredibly
>> *useful, and I’d be reluctant to see that thrown away.
>>
>> Dave
>>
>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>> https://github.com/jshier/swift-evolution/blob/master/
>> proposals/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>> ___
>> 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
>>
>
>
>
> ___
> 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] Adding Result to the Standard Library

[Dave DeLong via swift-evolution]

> On Nov 2, 2017, at 12:32 PM, Jon Shier  wrote:
> 
>   That’s been an argument against Result for 2 years now. The usefulness 
> of the type, even outside of whatever asynchronous language support the core 
> team comes up with, perhaps this year, perhaps next year, is still very high. 
> Even as something that just wraps throwing functions, or otherwise exists as 
> a local, synchronous value, it’s still very useful as way to encapsulate the 
> value/error pattern. That pattern will likely never go away. Additionally, 
> having the Result type in the standard library removes a source of conflict 
> between all other Result implementations, which are becoming more common.

  

There’s a lot of stuff I’m tired of implementing myself while waiting for the 
the core team “to lay the ground for”. Result is up there near the top of my 
list too.

Dave


> 
>> On Nov 2, 2017, at 2:26 PM, Tony Allevato > > wrote:
>> 
>> Given that the Swift team is currently working on laying the groundwork for 
>> asynchronous APIs using an async/await model, which would presumably tie the 
>> throwing cases more naturally into the language than what is possible using 
>> completion-closures today, are we sure that this wouldn't duplicate any 
>> efforts there or be made obsolete through other means?
>> 
>> In other words, while Result<> can be a very useful foundational component 
>> on its own, I think any proposal for it can't be made in isolation, but very 
>> much needs to consider other asynchronous work going on in the language.
>> 
>> 
>> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution 
>> > wrote:
>> You don’t lose it, it’s just behind `Error`. You can cast out whatever 
>> strong error type you need without having to bind an entire type to it 
>> generically. If getting a common error type out happens a lot, I usually add 
>> a convenience property to `Error` to do the cast for me. Plus, having to 
>> expose an entire new error wrapper is just a non starter for me and doesn’t 
>> seem necessary, given how Result is currently used in the community.
>> 
>> 
>> Jon
>> 
>> 
>>> On Nov 2, 2017, at 2:12 PM, Dave DeLong >> > wrote:
>>> 
>>> I think I’d personally rather see this done with a generic error as well, 
>>> like:
>>> 
>>> enum GenericResult {
>>> case success(T)
>>> case failure(E)
>>> }
>>> 
>>> And a typealias:
>>> 
>>> typealias Result = GenericResult
>>> 
>>> This would require an “AnyError” type to type-erase a specific Error, but 
>>> I’ve come across many situations where a strongly-typed error is incredibly 
>>> useful, and I’d be reluctant to see that thrown away.
>>> 
>>> Dave
>>> 
 On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
 > wrote:
 
 Swift-Evolution:
I’ve written a first draft of a proposal to add Result to the 
 standard library by directly porting the Result type used in Alamofire 
 to the standard library. I’d be happy to implement it (type and tests for 
 free!) if someone could point me to the right place to do so. I’m not 
 including it directly in this email, since it includes the full 
 implementation and is therefore quite long. (Discourse, please!) 
 
 https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
  
 
 
 
 Thanks, 
 
 Jon Shier
 
 
 ___
 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 
>> 
> 

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

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

That’s been an argument against Result for 2 years now. The usefulness 
of the type, even outside of whatever asynchronous language support the core 
team comes up with, perhaps this year, perhaps next year, is still very high. 
Even as something that just wraps throwing functions, or otherwise exists as a 
local, synchronous value, it’s still very useful as way to encapsulate the 
value/error pattern. That pattern will likely never go away. Additionally, 
having the Result type in the standard library removes a source of conflict 
between all other Result implementations, which are becoming more common.

> On Nov 2, 2017, at 2:26 PM, Tony Allevato  wrote:
> 
> Given that the Swift team is currently working on laying the groundwork for 
> asynchronous APIs using an async/await model, which would presumably tie the 
> throwing cases more naturally into the language than what is possible using 
> completion-closures today, are we sure that this wouldn't duplicate any 
> efforts there or be made obsolete through other means?
> 
> In other words, while Result<> can be a very useful foundational component on 
> its own, I think any proposal for it can't be made in isolation, but very 
> much needs to consider other asynchronous work going on in the language.
> 
> 
> On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution 
> > wrote:
> You don’t lose it, it’s just behind `Error`. You can cast out whatever strong 
> error type you need without having to bind an entire type to it generically. 
> If getting a common error type out happens a lot, I usually add a convenience 
> property to `Error` to do the cast for me. Plus, having to expose an entire 
> new error wrapper is just a non starter for me and doesn’t seem necessary, 
> given how Result is currently used in the community.
> 
> 
> Jon
> 
> 
>> On Nov 2, 2017, at 2:12 PM, Dave DeLong > > wrote:
>> 
>> I think I’d personally rather see this done with a generic error as well, 
>> like:
>> 
>> enum GenericResult {
>>  case success(T)
>>  case failure(E)
>> }
>> 
>> And a typealias:
>> 
>> typealias Result = GenericResult
>> 
>> This would require an “AnyError” type to type-erase a specific Error, but 
>> I’ve come across many situations where a strongly-typed error is incredibly 
>> useful, and I’d be reluctant to see that thrown away.
>> 
>> Dave
>> 
>>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
>>> > wrote:
>>> 
>>> Swift-Evolution:
>>> I’ve written a first draft of a proposal to add Result to the 
>>> standard library by directly porting the Result type used in Alamofire 
>>> to the standard library. I’d be happy to implement it (type and tests for 
>>> free!) if someone could point me to the right place to do so. I’m not 
>>> including it directly in this email, since it includes the full 
>>> implementation and is therefore quite long. (Discourse, please!) 
>>> 
>>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>>  
>>> 
>>> 
>>> 
>>> Thanks, 
>>> 
>>> Jon Shier
>>> 
>>> 
>>> ___
>>> 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 
> 

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

Re: [swift-evolution] Adding Result to the Standard Library

[Tony Allevato via swift-evolution]

Given that the Swift team is currently working on laying the groundwork for
asynchronous APIs using an async/await model, which would presumably tie
the throwing cases more naturally into the language than what is possible
using completion-closures today, are we sure that this wouldn't duplicate
any efforts there or be made obsolete through other means?

In other words, while Result<> can be a very useful foundational component
on its own, I think any proposal for it can't be made in isolation, but
very much needs to consider other asynchronous work going on in the
language.


On Thu, Nov 2, 2017 at 11:15 AM Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> You don’t lose it, it’s just behind `Error`. You can cast out whatever
> strong error type you need without having to bind an entire type to it
> generically. If getting a common error type out happens a lot, I usually
> add a convenience property to `Error` to do the cast for me. Plus, having
> to expose an entire new error wrapper is just a non starter for me and
> doesn’t seem necessary, given how Result is currently used in the community.
>
>
> Jon
>
>
> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
>
> I think I’d personally rather see this done with a generic error as well,
> like:
>
> enum GenericResult {
> case success(T)
> case failure(E)
> }
>
> And a typealias:
>
> typealias Result = GenericResult
>
> This would require an “AnyError” type to type-erase a specific Error, but
> I’ve come across many situations where a strongly-typed error is *incredibly
> *useful, and I’d be reluctant to see that thrown away.
>
> Dave
>
> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift-Evolution:
> I’ve written a first draft of a proposal to add Result to the standard
> library by directly porting the Result type used in Alamofire to the
> standard library. I’d be happy to implement it (type and tests for free!)
> if someone could point me to the right place to do so. I’m not including it
> directly in this email, since it includes the full implementation and is
> therefore quite long. (Discourse, please!)
>
>
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>
>
> Thanks,
>
> Jon Shier
>
>
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Logging facade

[Mike Kluev via swift-evolution]

on Date: Wed, 01 Nov 2017 10:58:38 -0700 Max Moiseev 
wrote:

>
> I believe you are looking for the «one true way of doing logging» that is
> community accepted, but it does not have to be in the standard library to
> be that. A standalone package would do just as well. swift-server-dev
> mailing list might be a better place to discuss this idea.
>

this is only tangentially relevant to what op is asking for - i remember
having to do something like this to trace every function enter / exit into
a log:

func foo() {
enter() { defer exit() }
...
...
}

and copy-paste that mantra at the beginning of every function. the enter /
exit would do some printing of the method name (#function) among other
things.

it was a bit annoying manually doing so in every method, and one of course
can dream of some automated built-in facility to the same effect. until
that time, manual tricks like this will do.

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

Re: [swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

You don’t lose it, it’s just behind `Error`. You can cast out whatever strong 
error type you need without having to bind an entire type to it generically. If 
getting a common error type out happens a lot, I usually add a convenience 
property to `Error` to do the cast for me. Plus, having to expose an entire new 
error wrapper is just a non starter for me and doesn’t seem necessary, given 
how Result is currently used in the community.


Jon

> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
> 
> I think I’d personally rather see this done with a generic error as well, 
> like:
> 
> enum GenericResult {
>   case success(T)
>   case failure(E)
> }
> 
> And a typealias:
> 
> typealias Result = GenericResult
> 
> This would require an “AnyError” type to type-erase a specific Error, but 
> I’ve come across many situations where a strongly-typed error is incredibly 
> useful, and I’d be reluctant to see that thrown away.
> 
> Dave
> 
>> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
>> > wrote:
>> 
>> Swift-Evolution:
>>  I’ve written a first draft of a proposal to add Result to the 
>> standard library by directly porting the Result type used in Alamofire to 
>> the standard library. I’d be happy to implement it (type and tests for 
>> free!) if someone could point me to the right place to do so. I’m not 
>> including it directly in this email, since it includes the full 
>> implementation and is therefore quite long. (Discourse, please!) 
>> 
>> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>>  
>> 
>> 
>> 
>> Thanks, 
>> 
>> Jon Shier
>> 
>> 
>> ___
>> 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] Adding Result to the Standard Library

[Dave DeLong via swift-evolution]

I think I’d personally rather see this done with a generic error as well, like:

enum GenericResult {
case success(T)
case failure(E)
}

And a typealias:

typealias Result = GenericResult

This would require an “AnyError” type to type-erase a specific Error, but I’ve 
come across many situations where a strongly-typed error is incredibly useful, 
and I’d be reluctant to see that thrown away.

Dave

> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution 
>  wrote:
> 
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> ___
> 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

[swift-evolution] Adding Result to the Standard Library

[Jon Shier via swift-evolution]

Swift-Evolution:
I’ve written a first draft of a proposal to add Result to the 
standard library by directly porting the Result type used in Alamofire to 
the standard library. I’d be happy to implement it (type and tests for free!) 
if someone could point me to the right place to do so. I’m not including it 
directly in this email, since it includes the full implementation and is 
therefore quite long. (Discourse, please!) 

https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
 



Thanks, 

Jon Shier


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

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

to sum up. so far the feedback on this proposal was:

1) generally in favour (e.g. to have ability of adding variables and
accessing privates at all)

2) the name "continuation" is used for something else

3) why not to use partials as they are in c#

4) having explicit names for continuations is unwanted because naming is
hard

5) the ledger list is unnecessary as anyone on the same module will be able
to change it anyway - false feel of protection.

here are my thoughts on it.

1) "generally in favour (e.g. to have ability of adding variables and
accessing privates at all)"
-- great! thank you.

2) "the name "continuation" is used for something else"
-- thought the same. let it be "part" instead of continuation

3) "why not to use partials as they are in c#"
-- my belief here is that just because i made my type partial (for my own
reasons, e.g. as a result of splitting a single-file class into a
multi-file) it does not necessarily mean I want other developers of my team
(on the same module) to add continuations / parts to my class. in other
words, while there are the module boundaries (the building walls) i still
want to see some partitions between the rooms of that building to have some
privacy.

4) "having explicit names for continuations is unwanted because naming is
hard"
-- every time I am adding extension now I want to label it somehow to
indicate it's purpose. if that extensions adds a protocol conformance (e.g.
"extension ViewController: UITableViewDataSource") the problem is not as
critical as the protocol (or the list of protocols) name itself can serve
the purpose of such an indication. if there is no such a protocol
conformance however i tend to add a "MARK: ThePurpose" or a comment
("extension ViewController /* ThePurpose */) and as the comments are not
checked and get out of sync every time i do this i wish there was a a more
explicit extension label in the language for this purpose. maybe that's
just me.

5) "the ledger list is unnecessary as anyone on the same module will be
able to change it anyway - false feel of protection."
-- to this i can give the same response as in (3). here is another example
that hopefully will clarify my point: we shall not really say that
"private" in swift is useless and "internal" shall be used instead of it
just because anyone in the same module can bypass it anyway: go to your
class and change the source from "private" to "internal" for their own
benefits, so why bother with private / fileprivate to begin with. so is
true in regards to the ledger: yes, it is true that anyone on the team
working on the same module has a physical ability to go to my class (the
class who's sole maintainer and "owner" is myself) and mess around it,
changing it's ledger along the way, or making it partial as in (3) or
changing it's privates to internal, or adding variables, etc. it's just
they shouldn't, at least not talking to me first. they won't be "behaving
properly" if they do.

some additional thoughts. ledger works similar to the c++ class definition
itself, which lists all the members of the class, just on a less granular
scope: while in C++ you have to go there every time you want to add, say, a
private method, with parts you go change the ledger very infrequently, to
add a group or functionalities. another tangentially similar feature of C++
is "friends". if you class have, say, 10 different extensions each
implementing a certain feature and you converted them to "parts" the ledger
list will contain 10 entries naming those features explicitly.

Mike

ps. by now i figured that discussing protection levels in swift is akin to
having a wonderful morning walk across a mine field
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution