Re: [swift-evolution] Abstract methods

> 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

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

> 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

Re: [swift-evolution] Abstract methods

> 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

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

> 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 >

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

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

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

> 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

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

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

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

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

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

> 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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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 > // ...

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

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 >

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

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,

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

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

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

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,

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

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

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

> 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

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

> 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

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

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

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

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

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

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,

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

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

Re: [swift-evolution] Abstract methods

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

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

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

Re: [swift-evolution] Abstract methods

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?

Re: [swift-evolution] Abstract methods

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 >

Re: [swift-evolution] Abstract methods

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

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

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

Re: [swift-evolution] Abstract methods

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

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

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

[swift-evolution] Abstract methods

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

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

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

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

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

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

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

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

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

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

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 >

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

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,

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

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

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

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

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

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

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

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 >

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

+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

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

> 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

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

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

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

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

Re: [swift-evolution] Logging facade

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.

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

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

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

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

[swift-evolution] Adding Result to the Standard Library

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.

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

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