Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

I put together some valid Swift 3 sample code in case anyone is having trouble understanding the discussion of rethrows. The behavior may not be immediately obvious. func ithrow() throws { throw E.e } func nothrow() {} func rethrower(f: () throws -> Void, g: () throws -> Void) rethrows { d

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

FWIW, I do think the foo(_) is the best variant. For me it means "no argument label AND no argument at all, as there is no `:` in it". foo(_:) means "no argument label BUT one argument". etc. As for `class()` IMO it is too cryptic. class(_) is more clear about what it *is*(because of _ as parame

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 11:53 AM, Vladimir.S wrote: > > I'm really sorry to interrupt your discussion, but could someone describe(or > point to some article etc) in two words why we need added complexity of typed > throws(in comparing to use documentation) Thrown errors already have an implicit

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 11:41 AM, Anton Zhilin wrote: > > 2017-02-23 20:09 GMT+03:00 Matthew Johnson >: > >> On Feb 23, 2017, at 10:58 AM, Anton Zhilin > > wrote: >> >> See some inline response below. >> Also, have you seen the issue

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 9:54 AM, Karl Wagner wrote: > > >> On 23 Feb 2017, at 18:40, David Sweeris > > wrote: >> >> >> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> > > Are there Number type

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On 23 Feb 2017, at 18:40, David Sweeris wrote: > > > On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Are there Number types which can’t be Comparable? Complex numbers. I believe `Number` is designed to allow

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

I'm really sorry to interrupt your discussion, but could someone describe(or point to some article etc) in two words why we need added complexity of typed throws(in comparing to use documentation) and *if* the suggested solution will guarantee that some method can throw only explicitly defined

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 11:31 AM, David Sweeris wrote: > > > On Feb 23, 2017, at 07:33, plx via swift-evolution > wrote: >> >> Next quibble: `Magnitude` being defined as the “absolute value” of the >> underlying type seems a bit nonsensical if e.g. `Number` is

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 20:09 GMT+03:00 Matthew Johnson : > > On Feb 23, 2017, at 10:58 AM, Anton Zhilin wrote: > > See some inline response below. > Also, have you seen the issue I posted in Proposal thread? There is a way > to create an instance of "any" type. > > > Yes, I saw that. There is no problem wit

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 22, 2017, at 23:52, Karl Wagner via swift-evolution > wrote: > > Are there Number types which can’t be Comparable? >>> >>> Complex numbers. I believe `Number` is designed to allow a complex number >>> type to conform. >>> > > Magnitude could be comparable then. For vec

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

> On Feb 23, 2017, at 06:49, Xiaodi Wu via swift-evolution > wrote: > > Nice. That works well. >> On Thu, Feb 23, 2017 at 08:36 Ben Rimmington wrote: >> >> > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote: >> > >> > What happens when you need the backticks for the function name itself? We >> > ca

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

> On Feb 23, 2017, at 07:33, plx via swift-evolution > wrote: > > Next quibble: `Magnitude` being defined as the “absolute value” of the > underlying type seems a bit nonsensical if e.g. `Number` is intended to be > adoptable by complex numbers (let alone quaternions, matrices, and whatnot).

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

> On Feb 23, 2017, at 10:58 AM, Anton Zhilin wrote: > > See some inline response below. > Also, have you seen the issue I posted in Proposal thread? There is a way to > create an instance of "any" type. Yes, I saw that. There is no problem with that at all. As I point out in the analysis be

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

See some inline response below. Also, have you seen the issue I posted in Proposal thread? There is a way to create an instance of "any" type. 2017-02-23 3:37 GMT+03:00 Matthew Johnson via swift-evolution < swift-evolution@swift.org>: > # Analysis of the design of typed throws > > ## Problem > >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 23, 2017, at 12:06 AM, Karl Wagner wrote: > > >> On 22 Feb 2017, at 21:13, Joe Groff wrote: >> >>> >>> On Feb 21, 2017, at 8:50 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> On Feb 20, 2017, at 11:12 PM, John McCall wrote: > As you know, I still think that adding

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

+1 on most of it, with some minor quibbles. First quibble: between `Number` and `Arithmetic` I’d prefer `Arithmetic`; this is 50/50 aesthetics and concern about clarity vis-a-vis `(NS)Number`, `(NS)DecimalNumber`, and so on. Next quibble: `Magnitude` being defined as the “absolute value” of the

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

Nice. That works well. On Thu, Feb 23, 2017 at 08:36 Ben Rimmington wrote: > > > On 23 Feb 2017, at 14:23, Xiaodi Wu wrote: > > > > What happens when you need the backticks for the function name itself? > We can't nest them. > > func `class`() {} > > `class`() // Function call. > > `class()` // F

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

> On 23 Feb 2017, at 14:23, Xiaodi Wu wrote: > > What happens when you need the backticks for the function name itself? We > can't nest them. func `class`() {} `class`() // Function call. `class()` // Function reference. -- Ben ___ swift-evolution

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 23 Feb 2017, at 12:49, Vladimir.S wrote: > > On 23.02.2017 14:17, Haravikk wrote: >> >>> On 22 Feb 2017, at 21:25, Patrick Pijnappel >> > wrote: >>> >>> To summarize, there's one ambiguous case we'd need to resolve: >>> >>> func foo(_ x: Int, reportingO

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

The back tick option is interesting. Back tick means "don't treat this as an expression" which allows us to use keywords in certain areas but have them. Act as something that isn't a keyword. let f = `foo()` However looking at it like this it almost looks like a string. On Thu, Feb 23, 2017 at 9:

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

What happens when you need the backticks for the function name itself? We can't nest them. On Thu, Feb 23, 2017 at 08:16 Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > > On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote: > > *Compound name syntax* — foo(_:), foo(bar:)

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

> On 22 Feb 2017, at 07:05, Jacob Bandes-Storch wrote: > > Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to > disambiguate references to functions. (You might've used it inside a > #selector expression.) But there's currently no compound name for a function > with no argum

Re: [swift-evolution] Analysis of existing scopes

> On Feb 23, 2017, at 4:47 AM, Joanna Carter via swift-evolution > wrote: > > And now I find, what I consider to be, a very peculiar anomaly in method > visibility. > > private class PrivateBaseClass > { > internal func internalFunc() { } > > public func publicFunc() { } > > open func op

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 23, 2017, at 4:40 AM, Anton Mironov wrote: > > >> On Feb 23, 2017, at 4:28 AM, Matthew Johnson > > wrote: >> >>> >>> On Feb 22, 2017, at 7:13 PM, Anton Mironov >> > wrote: >>> On Feb 23, 2017, at 02:19, Matthe

Re: [swift-evolution] [Pitch] Allow trailing argument labels

On 23.02.2017 14:17, Haravikk wrote: On 22 Feb 2017, at 21:25, Patrick Pijnappel mailto:patrickpijnap...@gmail.com>> wrote: To summarize, there's one ambiguous case we'd need to resolve: func foo(_ x: Int, reportingOverflow) func foo(_ x: Int, _ reportingOverflow: Bool) let reportingOverflow

Re: [swift-evolution] [Pitch] Allow trailing argument labels

why not just require a leading dot, like an enum, rather than a colon? less syntax to learn, and it still eliminates the extra type. Begin Message Group: gmane.comp.lang.swift.evolution MsgID: >On 22 Feb 2017, at 21:25, Patrick Pijnappel > wrote: > >To summarize, t

Re: [swift-evolution] [Pitch] Allow trailing argument labels

> On 22 Feb 2017, at 21:25, Patrick Pijnappel > wrote: > > To summarize, there's one ambiguous case we'd need to resolve: > > func foo(_ x: Int, reportingOverflow) > func foo(_ x: Int, _ reportingOverflow: Bool) > > let reportingOverflow = true > foo(5, reportingOverflow) // Ambiguous > > On

Re: [swift-evolution] Analysis of existing scopes

And now I find, what I consider to be, a very peculiar anomaly in method visibility. private class PrivateBaseClass { internal func internalFunc() { } public func publicFunc() { } open func openFunc() { } } private class PrivateDerivedClass : PrivateBaseClass { fileprivate override

Re: [swift-evolution] [Proposal] Guarded self in closures

> On Feb 23, 2017, at 4:28 AM, Matthew Johnson wrote: > >> >> On Feb 22, 2017, at 7:13 PM, Anton Mironov > > wrote: >> >>> >>> On Feb 23, 2017, at 02:19, Matthew Johnson >> > wrote: >>> On Feb 22, 2017, at 6:06 PM, Ant

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

> On Feb 22, 2017, at 5:32 PM, Ben Cohen via swift-evolution > wrote: > >> On Feb 22, 2017, at 10:42 AM, Nate Cook via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Oops, left out that there's this horrifying way of writing it right now: >> >> Nobody wants that. >> > >

Re: [swift-evolution] [Re-Review] SE-0104: Protocol-oriented integers

>> >> Are there Number types which can’t be Comparable? >> >> Complex numbers. I believe `Number` is designed to allow a complex number >> type to conform. >> Magnitude could be comparable then. For vectors, matrices and complex numbers, “magnitude” typically refers to a scalar. I don’t thi

Re: [swift-evolution] [Pitch] Typed throws

> On 22 Feb 2017, at 21:13, Joe Groff wrote: > >> >> On Feb 21, 2017, at 8:50 PM, Chris Lattner via swift-evolution >> wrote: >> >> On Feb 20, 2017, at 11:12 PM, John McCall wrote: As you know, I still think that adding typed throws is the right thing to do. I understand your co