Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 12:59 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Mar 01 2017, Douglas Gregor > wrote: > >>> On Mar 1, 2017, at 1:55 AM, Jonathan Hull wrote: >>> >>> What I would like is a way to specialize a generic function in a bloc

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Submodules will, I hope, afford us the ability to share meaningfully arranged API. In an ideal scenario, I could have a module that has all of the smaller pieces of 'utilities and conveniences' that one builds up broken into submodules. Importing one of the submodules from its enclosing module sho

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 1, 2017, at 11:56 AM, David Hart wrote: > >> 2. Normally, references within the module to submodule symbols need to be >> prefixed with the submodule name. (That is, in top-level `Foo` code, you >> need to write `Bar.Baz` to access `Foo.Bar.Baz`). As a convenience, you can >> import a

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

Sent from my iPad > On Mar 2, 2017, at 9:06 PM, T.J. Usiyan wrote: > > +1 overall. prefer this approach over the "scope based" approach in the other > proposal Can you elaborate? What problems are you hoping submodules will address? > >> On Wed, Feb 22, 2017 at 10:10 AM, Matthew Johnson v

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

+1 overall. prefer this approach over the "scope based" approach in the other proposal On Wed, Feb 22, 2017 at 10:10 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 21, 2017, at 11:54 PM, Robert Widmann > wrote: > > > On Feb 22, 2017, at 12:41 AM, Matthew J

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

Sent from my iPad > On Mar 2, 2017, at 6:56 PM, Tony Allevato via swift-evolution > wrote: > > newtype feels like a leaky abstraction. Since the new type carries all the > protocol conformance and members of the original type, in your example, I > could add or divide RecordIds; but if they'

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 2, 2017, at 6:16 PM, Charles Srstka wrote: > >> On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution >> wrote: >> >> I’d like to investigate separating Objective-C bridging from the behavior of >> the as/as?/is operator family again for Swift 4. Last year, I proposed >> SE–00

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution > wrote: > > I’d like to investigate separating Objective-C bridging from the behavior of > the as/as?/is operator family again for Swift 4. Last year, I proposed > SE–0083 >

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

newtype feels like a leaky abstraction. Since the new type carries all the protocol conformance and members of the original type, in your example, I could add or divide RecordIds; but if they're database concepts, why would I want to do that? If the original type were extended to add members or pr

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 2, 2017, at 4:24 PM, Joe Groff wrote: > > >> On Mar 2, 2017, at 3:09 PM, Jaden Geller > > wrote: >> >> +1. I’ve always found the bridging casting behavior confusing. Definitely >> would agree with removing it—especially given the interop problems—but on

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 2, 2017, at 3:09 PM, Jaden Geller wrote: > > +1. I’ve always found the bridging casting behavior confusing. Definitely > would agree with removing it—especially given the interop problems—but only > if a good solution was found for imported APIs. > > With `NSNumber`-involving APIs, I

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

2017-03-03 2:13 GMT+03:00 Slava Pestov : Does newtype add any new capability that’s not already covered by defining > a struct? > newtype would forward all members and conformances of the underlying type: newtype RecordId = Int let x: RecordId = 5let y = x + 10 extension RecordId { func load(

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

I’m not OP, but I imagine you can pattern match on the type. I don’t think that’s a compelling reason to add this feature though. I’d rather have active-patterns for structs. > On Mar 2, 2017, at 3:13

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> On Mar 2, 2017, at 3:24 AM, Anton Zhilin via swift-evolution > wrote: > > I think that tuples should remain what they are now. Static-length vectors > should be types on their own and interact with tuples, with structs and with > Array<…> in the same way. > > newtype should be what enables

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

+1. I’ve always found the bridging casting behavior confusing. Definitely would agree with removing it—especially given the interop problems—but only if a good solution was found for imported APIs. With `NSNumber`-involving APIs, I think it might be reasonable to add an Objective-C annotation t

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

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

[swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

This is an intriguing proposal. There are parts I like, and parts that I will have to think about more before drawing an opinion. Personally, I would like to see public classes be inheritable, public protocols be conformable, and public enums be switchable, unless specified otherwise. However I wi

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 1, 2017, at 1:56 PM, David Hart wrote: > > Wonderful comments. I really enjoy your take on submodules which keeps most > of the power while keeping the simplicity. Comments below: > > > Sent from my iPhone > > On 1 Mar 2017, at 07:55, Brent Royal-Gordon via swift-evolution > mailto

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 1, 2017, at 12:55 AM, Brent Royal-Gordon > wrote: > >> On Feb 24, 2017, at 11:34 AM, Matthew Johnson via swift-evolution >> wrote: >> >> Scope-based submodules >> >> • Proposal: SE- >> • Authors: Matthew Johnson >> • Review Manager: TBD >> • Status: Awaiting

Re: [swift-evolution] Swift error handling suggestion

> On Mar 2, 2017, at 12:39 PM, Jon Shier via swift-evolution > wrote: > > Both of your proposals seem contrary to the very reasons Swift’s error > handling is the way it is, so it’s unlikely they’ll find any support. I’m not > aware of any “error handling” manifesto, as Swift 2 was created be

Re: [swift-evolution] Swift error handling suggestion

Both of your proposals seem contrary to the very reasons Swift’s error handling is the way it is, so it’s unlikely they’ll find any support. I’m not aware of any “error handling” manifesto, as Swift 2 was created before the evolution process, but I’m sure someone has something to share about why

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

+1. Removing this magic is a good idea. > On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution > wrote: > > I’d like to investigate separating Objective-C bridging from the behavior of > the as/as?/is operator family again for Swift 4. Last year, I proposed > SE–0083 >

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

One use-case that springs immediately to mind is creating ranges of magnitudes. It is not sufficient to use abs() because that returns the same type which may not be comparable. Also, a fairly common operation on complex numbers (or indeed any metric space) is to see if two values are within dista

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

The Magnitude requirement was meant to be just Numeric (which does not refine Comparable), and only due to the lack of recursive constraints was desugared into Equatable and ExpressibleByIntegerLiteral. Nevin has a very valid point that the very definition of Magnitude is about the ordering of t

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

While it is true that the complex number itself is not comparable, the magnitude of a complex number is only a scalar, and therefore it's magnitude IS comparable. It's only about the comparability of the magnitude, not about the number itself. The number might actually not be comparable. Kind Rega

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

Hi Joe, the point made here is about the magnitude of complex numbers. The magnitude of one complex number can be compared to the magnitude of a second number. Kind Regards On Thu, Mar 2, 2017 at 6:21 PM, Joe Groff wrote: > > On Mar 2, 2017, at 6:22 AM, Björn Forster > wrote: > > Hello Joe,

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

> On Mar 2, 2017, at 6:22 AM, Björn Forster > wrote: > > Hello Joe, > I wanted to ask kindly if it would be possible that the core team adds to the > rationale the design decision behind > associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral > being not comparable. It was point

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

Also not core team, but I didn’t realize this was missing during the review. If I had I would have spoken up, because mathematically a magnitude is *defined* as something that can be compared to see which underlying object is bigger. It is a measure of size, and it exists so that the sizes of obje

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

> On Mar 2, 2017, at 06:22, Björn Forster via swift-evolution > wrote: > > Hello Joe, > I wanted to ask kindly if it would be possible that the core team adds to the > rationale the design decision behind > associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral > being not compar

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

Hello Joe, I wanted to ask kindly if it would be possible that the core team adds to the rationale the design decision behind associatedtype Magnitude : Equatable, ExpressibleByIntegerLiteral being not comparable. It was pointed out by several reviewers that it is against all intuition that a s

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

Actually the generics manifesto has a nice solution on how we could extend tuples in the future. Parameterized extensions + variadic generics could allow us a lot. I played with a simple sketch on how it could be enhanced. Especially I personally like the ability of fixed vs. unbound parameter

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

I think that tuples should remain what they are now. Static-length vectors should be types on their own and interact with tuples, with structs and with Array<…> in the same way. newtype should be what enables extension of tuples: newtype Money = (Int, Int) extension Money: CustomStringConvertible

Re: [swift-evolution] [Discussion] Simplifying case syntax

Hi Erica, thanks for restarting the discussion—I hope that it will be considered on topic for stage 2. I agree that the part with preventing let .case(existingVar, newVar) should be moved out of the proposal, because these issues are orthogonal. So the options with ~= and := will differ only in th

[swift-evolution] Swift error handling suggestion

I was writing some code yesterday which utilized throwing funcs and I found some inconveniences which I think could be improved in some future version of Swift. 1. *Default error handling* Swift, unlike most languages, requires us to put try, try? or try! before calling throwing funcs. When using