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

On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Feb 17 2017, Joe Groff wrote: > > > Experience in other languages like Rust and Haskell that use > > Result-based error propagation suggests that a single error

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

Sent from my iPhone > On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution > wrote: > > I often find myself running into situations where I'll receive "Ambiguous use > of..." for overloaded functions or operators. In every case these situations > would be

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

on Mon Feb 27 2017, Daniel Leping wrote: > Well, as Dave pointed, you can very rarely recover from an error, which IMO > is absolutely true. > > If your operation fails you don't really care unless you can recover. And > you know your cases, which you can recover from (in reality one usually >

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

I'm also annoyed by this, so I second this proposal. To give an explicit example of the kind of code that can lead to frustration and a desire for "T != Type": protocol P1 {} protocol P2 { // Now, any type conforming to P1 and P2 may not be added to itself static func +(lhs:

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

> On 28 Feb 2017, at 02:43, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Feb 27, 2017, at 7:19 PM, Daniel Leping > wrote: > >> Well, as Dave pointed, you can very

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

Sent from my iPad > On Feb 27, 2017, at 7:19 PM, Daniel Leping wrote: > > Well, as Dave pointed, you can very rarely recover from an error, which IMO > is absolutely true. > > If your operation fails you don't really care unless you can recover. And you > know

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

On Mon, Feb 27, 2017 at 10:07 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > I think the most important goal is to end up with the right set of > operator and identifier characters for *Swift*. The Unicode guidelines are > a useful tool for that purpose, and

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

> On Feb 27, 2017, at 2:08 PM, Matthew Johnson wrote: > >> >> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >> > wrote: >> >> Add more layers, and it can be very mysterious why a call failed.

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

Well, as Dave pointed, you can very rarely recover from an error, which IMO is absolutely true. If your operation fails you don't really care unless you can recover. And you know your cases, which you can recover from (in reality one usually does it in optimization phase, though). What else do

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

on Mon Feb 27 2017, Matthew Johnson wrote: > If you don't believe typed errors will improve your code or if you > just don't want to deal with typed errors, just don't use them! As I've tried to point out, it's not that simple. You have to consider the complexity cost of adding a feature,

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

Sent from my iPad > On Feb 27, 2017, at 8:21 PM, Dave Abrahams wrote: > > >> on Mon Feb 27 2017, Matthew Johnson wrote: >> >> If you don't believe typed errors will improve your code or if you >> just don't want to deal with typed errors, just don't use them! > > As

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

On Sun, Feb 26, 2017 at 11:50 AM, Nevin Brackett-Rozinsky via swift-evolution wrote: > This looks very good Xiaodi, and I have a few thoughts about it. > > First, is the intent that Swift will follow future changes to Unicode > operator recommendations, or that Swift

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Oh, and to your later email: The reason why we wanted product type to use subclasses, and not a type field, is that we imagine product types growing to encompass other things for which it does not make sense to share the fields across all other products. Right now the Product type looks very

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Having watched this conversation from the sidelines, I just wanted to chime in from a more distant view: Originally, I thought this proposal was very nice because it made a good argument as to why enum cases would benefit from being function-like. It follows naturally that form should follow

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

-- Brent Royal-Gordon Sent from my iPhone > On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution > wrote: > > Here is an example of the kind of thing I have in mind: > > enum PlayerState { > case stopped > sub case playing(with track: Track) > >

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

I think the most important goal is to end up with the right set of operator and identifier characters for *Swift*. The Unicode guidelines are a useful tool for that purpose, and get us a long way toward where we want to be. However at the end of the day we should weigh our success by how well we

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

What I like about ‘hidden’ vs export of nested submodules is that you can freely intermix those declarations in your code (like you can with private now). >>> >>> Yeah, this is an advantage. It’s not a bad idea, but it’s not a >>> replacement for submodules either. They are

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

> On 28 Feb 2017, at 01:50, Daniel Dunbar wrote: > > Hi David, > > We discussed the leading-dot & capitalization issue today again... this was > already something we weren't really happy about, but had chosen to live with > (using the "identity" rule to determine

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

+ 1 I personally find this frustrating, but at the same time Im curious as to what the argument against introducing this is. - Nick On Tue, Feb 28, 2017 at 3:21 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > > Sent from my iPhone > > On Feb 27, 2017, at 16:34,

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

+1 I would also welcome to be able to use "or" and "and" logical operators (not only the not operator) on these constraints. I have sometimes generic functions whose code is identical but is written twice: first with 'where T=P1' and then with 'where T=P2', being able to write for instance 'where

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution > wrote: > On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution > > wrote: > >> I suggest to take a look at the topics "Variadics as

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

> On Feb 25, 2017, at 8:28 AM, Xiaodi Wu via swift-evolution > wrote: > > I assume that Number being renamed Numeric implies SignedNumber being renamed > SignedNumeric? That is correct. > On Sat, Feb 25, 2017 at 09:06 Ben Rimmington via swift-evolution >

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

IMHO, there are two kinds of responses to errors - a specific response, and a general one. Only the calling code knows how it will deal with errors, so a “typed throws” is the function guessing possible calling code behavior. The problem is, that gives four possible combinations - two where the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: > > Before I start revising this proposal, there are a couple of open questions > I’d like to discuss with the community and the core team. > > The first question relates to the purpose of having a “internal” argument > name.

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution > wrote: > > I suggest to take a look at the topics "Variadics as an Attribute" and "array > splatting for variadic parameters" and >

Re: [swift-evolution] Strings in Swift 4

Hi David W. please read inline responses > On 25 Feb 2017, at 07:26, David Waite wrote: > > Ted, > > It might have helped if instead of being called String and Character, they > were named Text and ExtendedGraphemeCluster. Imho,l “text” maybe, but in computer

Re: [swift-evolution] [Manifesto] Ownership

> On Feb 25, 2017, at 11:41 AM, plx via swift-evolution > wrote: > 1: Collection Composition > > As much as the high-level picture is focused on safety, I’d just like to > request a strong focus on making sure the eventual ownership system addresses > the common

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 10:39 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >>>

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

> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution > wrote: > > > >> On 24 Feb 2017, at 02:05, Ben Cohen wrote: >> >> Regarding the “Number” protocol: it was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 1:39 PM, Daniel Duan wrote: >> On Feb 27, 2017, at 10:00 AM, Joe Groff wrote: >> >> >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >>> >>> Before I start revising this proposal, there are a couple of open

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 12:46 PM, Joe Groff wrote: > > >> On Feb 27, 2017, at 10:39 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution >>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Sent from my iPad > On Feb 27, 2017, at 12:00 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >> >> Before I start revising this proposal, there are a couple of open questions >> I’d like to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Daniel Duan Sent from my iPhone > On Feb 27, 2017, at 10:00 AM, Joe Groff wrote: > > >> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >> >> Before I start revising this proposal, there are a couple of open questions >> I’d like to discuss with the

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

On Mon, Feb 27, 2017, at 04:05 PM, Daniel Leping via swift-evolution wrote: > David, IMHO, all you say is absolutely true and typed throws might > work well, but in theoretic idealistic world. In reality though, you > end having more exception types than data types, feature cost rises >

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

> On Feb 27, 2017, at 5:01 PM, Dave Abrahams wrote: > > > on Mon Feb 27 2017, Matthew Johnson wrote: > >>> On Feb 27, 2017, at 4:20 PM, Dave Abrahams wrote: >>> >>> >>> I'm sorry, I don't see any substantive difference, based on what you've >>>

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

> On Feb 27, 2017, at 3:34 PM, Joe Groff via swift-evolution > wrote: > > >> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution >> > wrote: >> >> >> On Mon, 27 Feb 2017 at 8:44 Dave Abrahams

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

> On Feb 27, 2017, at 11:05 AM, Jordan Rose via swift-evolution > wrote: > > >> On Feb 25, 2017, at 07:06, Ben Rimmington via swift-evolution >> wrote: >> >>

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

> On Feb 27, 2017, at 4:20 PM, Dave Abrahams wrote: > > > on Mon Feb 27 2017, Matthew Johnson > wrote: > >>> On Feb 27, 2017, at 10:48 AM, Dave Abrahams wrote: >>> >>> >>> on Mon Feb 27 2017, Matthew Johnson

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

> On Feb 27, 2017, at 4:44 PM, Zach Waldowski via swift-evolution > wrote: > > On Mon, Feb 27, 2017, at 04:05 PM, Daniel Leping via swift-evolution wrote: >> David, IMHO, all you say is absolutely true and typed throws might work >> well, but in theoretic idealistic

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

on Mon Feb 27 2017, Matthew Johnson wrote: >> On Feb 27, 2017, at 4:20 PM, Dave Abrahams wrote: >> >> >> I'm sorry, I don't see any substantive difference, based on what you've >> written here, between this feature and const. > > Let me give it one more shot and then

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

David, IMHO, all you say is absolutely true and typed throws might work well, but in theoretic idealistic world. In reality though, you end having more exception types than data types, feature cost rises exponentially and the code becomes cluttered with all the wrapping. I seriously don't

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

on Mon Feb 27 2017, Joe Groff wrote: >> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >> >> Before I start revising this proposal, there are a couple of open questions >> I’d like to discuss > with the community and the core team. >> >> The first question relates to the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Feb 27 2017, Joe Groff wrote: > >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >>> >>> Before I start revising this proposal, there are a couple of open

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On 27 Feb 2017, at 19:09, Jose Cheyo Jimenez wrote: > >> >> On Feb 27, 2017, at 9:59 AM, Haravikk > > wrote: >> >> >>> On 27 Feb 2017, at 17:10, Jose Cheyo Jimenez via swift-evolution >>>

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

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution > wrote: > > IMHO, there are two kinds of responses to errors - a specific response, and a > general one. Only the calling code knows how it will deal with errors, so a > “typed throws” is the function

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> These is very unfortunate as a solution for “spreading” a collection or tuple > so that It can be applied to function taking a variadic. > It makes sense on the declaration site but not on the call site. > > someFunc(@nonVariadic [1]) > someFunc(@variadic [1]) > > There is nothing special

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

> On Feb 27, 2017, at 4:19 AM, Daniel Leping via swift-evolution > wrote: > > > On Mon, 27 Feb 2017 at 8:44 Dave Abrahams via swift-evolution > > wrote: > > on Fri Feb 17 2017, Joe Groff

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

-1 as written due to the impedance mismatch with importing NS_STRING_ENUM and NS_EXTENSIBLE_STRING_ENUM. Exporting to Objective-C should export a typedef and several constants, not a class. Exporting generated accessors to Objective-C is unnecessary as you have -isEqual: and -hashValue on NSString

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote: > >> These is very unfortunate as a solution for “spreading” a collection or >> tuple so that It can be applied to function taking a variadic. >> It makes sense on the declaration site but not on the call site. >> >>

Re: [swift-evolution] [pitch] Make swift enum string available to Objc

NS_EXTENSIBLE_STRING_ENUM Turns a groups of NSStrings into a struct. What do you suggest for the reverse? On Mon, Feb 27, 2017 at 4:39 PM Zach Waldowski via swift-evolution < swift-evolution@swift.org> wrote: > -1 as written due to the impedance mismatch with importing NS_STRING_ENUM > and

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

+1 to all of this. I completely support the proposal now. Thanks, Jon > On Feb 23, 2017, at 6:05 PM, Ben Cohen via swift-evolution > wrote: > > Hi everyone, > > The core team met and reviewed the discussion of this proposal so far, and > had the following

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

> On 27 Feb 2017, at 11:21, Ankit Aggarwal wrote: > > Hi David, > > Thanks for the feedback! Comments inline: > > > On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev > > wrote: > Was looking

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

> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution > wrote: > > IMHO, there are two kinds of responses to errors - a specific response, and a > general one. Only the calling code knows how it will deal with errors, so a > “typed throws” is the function

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

on Mon Feb 27 2017, Matthew Johnson wrote: >> On Feb 27, 2017, at 12:46 PM, Joe Groff wrote: >> >> That still feels like it's going against the behavior of the binding >> name in other declarations. Personally, `case .playing(with: let x)` >> doesn't bother me that much,

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 26, 2017, at 10:47 PM, Jonathan Hull wrote: > >> >> On Feb 25, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 25, 2017, at 4:01 PM, Jonathan Hull >> >

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi David, Thanks for the feedback! Comments inline: On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev < swift-build-...@swift.org> wrote: > Was looking forward to this :) here are my comments: > > On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution < >

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

I often find myself running into situations where I'll receive "Ambiguous use of..." for overloaded functions or operators. In every case these situations would be easily solved if I could specify "Generic != CertainType" in the where clause of one of the overloads so I can disambiguate the cases.

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi David, We discussed the leading-dot & capitalization issue today again... this was already something we weren't really happy about, but had chosen to live with (using the "identity" rule to determine what was a type and what wasn't). However, as we talked it over more we: 1. Felt that for