Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

I guess allowing a list of versions to be specified is interesting for continuous integration. That would allow people to test their code under all intended supported version. Dimitri > On 8 Feb 2017, at 08:19, Martin Waitz via swift-evolution > wrote: > > Hello, > >> The review of SE-0151

Re: [swift-evolution] Warning when omitting default case for imported enums

I have no objection against removing that warning. The warning seems unnecessary to me. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 07 Feb 2017, at 22:13, Tanner Nelson wrote: > >

Re: [swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

Hello, > The review of SE-0151 “Package Manager Swift Language Compatibility Version" > begins now and runs through February 13, 2017. The proposal is available > here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility

Re: [swift-evolution] Recursive protocol constraints

> On Feb 7, 2017, at 9:12 PM, Austin Zheng via swift-evolution > wrote: > > I would like to get the PR revised and into the review process soon, as it > should have been a month ago. Is there a good place to review the in-progress > work? I think it would go a long way to help complete the au

Re: [swift-evolution] Recursive protocol constraints

I would like to get the PR revised and into the review process soon, as it should have been a month ago. Is there a good place to review the in-progress work? I think it would go a long way to help complete the auditing of the necessary standard library changes. (Alternately, if anyone is inter

Re: [swift-evolution] Compile-time generic specialization

> On Feb 5, 2017, at 8:28 AM, Abe Schneider via swift-evolution > wrote: > The suggested method to get around this issue is to use a protocol to create > a witness table, allowing for runtime dispatch. However, this approach is not > ideal in all cases because: (a) the overhead of runtime dis

Re: [swift-evolution] Recursive protocol constraints

Sent from my iPhone > On Feb 7, 2017, at 3:05 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Tue Feb 07 2017, Rex Fenley wrote: >> >> Does "Permit where clauses to constrain associated types" ( >> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-type

Re: [swift-evolution] Compile-time generic specialization

Sent from my iPhone > On Feb 7, 2017, at 4:13 AM, Abe Schneider wrote: > > Thank you for the explanation, that makes sense. Do you think it makes sense > to create a proposal to allow handling of specialized overloads in Swift? I don't think it's a particularly good time in Swift's evolution

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 6:16 PM, Dany St-Amant via swift-evolution > wrote: > > > Le 7 févr. 2017 à 14:45, Robert Widmann via swift-evolution > mailto:swift-evolution@swift.org>> a écrit : > >> I lean +1, but this answer on its own seems incomplete. Exhaustiveness is >> an important property,

Re: [swift-evolution] Warning when omitting default case for imported enums

> Le 7 févr. 2017 à 14:45, Robert Widmann via swift-evolution > a écrit : > > I lean +1, but this answer on its own seems incomplete. Exhaustiveness is an > important property, and it’s not clear what happens here now when you fall > through a “complete” case tree without matching a pattern,

Re: [swift-evolution] Recursive protocol constraints

on Tue Feb 07 2017, Rex Fenley wrote: > Does "Permit where clauses to constrain associated types" ( > https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md) > also > include "Recursive protocol constraints"? The "Motivation" section seems to > imply

Re: [swift-evolution] Strings in Swift 4

> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > I now assume that: > 1. -= a “plain” Unicode character (codepoint?) can result in one > glyph.=- What do you mean by “plain”? Characters in some Unicode scripts are by no means “plain”. They can affect

[swift-evolution] Recursive protocol constraints

Does "Permit where clauses to constrain associated types" ( https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md) also include "Recursive protocol constraints"? The "Motivation" section seems to imply this. If not, will this be making it into Swift 4?

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 1:44 PM, Tanner Nelson wrote: > > To give a concrete example, some of the issues have arisen from using enums > as Swift.Errors. > > ``` > public enum SocketError: Error { > case closed > } > ``` > > Then we find some new error that was unaccounted for and want to add

[swift-evolution] SE-0152: Package Manager Tools Version

Hello Swift community, The review of SE-0152 "Package Manager Tools Version" begins now and runs through February 13, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md Reviews are an important par

[swift-evolution] SE-0151: Package Manager Swift Language Compatibility Version

Hello Swift community, The review of SE-0151 “Package Manager Swift Language Compatibility Version" begins now and runs through February 13, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatib

Re: [swift-evolution] Warning when omitting default case for imported enums

To give a concrete example, some of the issues have arisen from using enums as Swift.Errors. ``` public enum SocketError: Error { case closed } ``` Then we find some new error that was unaccounted for and want to add a new case. ``` public enum SocketError: Error { case closed case

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 1:21 PM, Tanner Nelson wrote: > > That's awesome. It looks like `(planned) Open and closed enums` is exactly > what I'm looking for. > > Would it help if I created a concrete proposal for that or is it something > the Swift team already has brewing? > Note that open en

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 I prefer to have enums enforce that all cases are met otherwise use a default value. If an API changes and adds new cases I want to know about it so that I can do something about it! If we hide it then weird and mysterious bugs might creep up On Tue, Feb 7, 2017 at 4:22 PM Tanner Nelson via sw

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 3:01 PM, Michael Ilseman via swift-evolution > wrote: > > BTW, this will likely be part of the eventual design of “open”/resilient > enums ala > https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums >

Re: [swift-evolution] [Discussion] mailing list alternative

> On Feb 7, 2017, at 1:23 PM, Daniel Duan via swift-evolution > wrote: > > >> On Feb 7, 2017, at 1:15 PM, Tino Heth <2...@gmx.de > >> wrote: >> >>> Believe it or not, not everyone in the world can afford the device and data >>> plan for a JavaScript-rich web front end (I

Re: [swift-evolution] [Discussion] mailing list alternative

> On Feb 7, 2017, at 1:15 PM, Tino Heth <2...@gmx.de> wrote: > >> Believe it or not, not everyone in the world can afford the device and data >> plan for a JavaScript-rich web front end (I'm aware of the mobile apps). I >> remember only being able to buy an iPod Touch myself when it came out. I

Re: [swift-evolution] [Discussion] mailing list alternative

On Tue, Feb 7, 2017 at 1:15 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > Believe it or not, not everyone in the world can afford the device and > data plan for a JavaScript-rich web front end (I'm aware of the mobile > apps). I remember only being able to buy an iPod Tou

Re: [swift-evolution] Warning when omitting default case for imported enums

That's awesome. It looks like `(planned) Open and closed enums` is exactly what I'm looking for. Would it help if I created a concrete proposal for that or is it something the Swift team already has brewing? Sent from my iPhone > On Feb 7, 2017, at 22:01, Michael Ilseman wrote: > > BTW, thi

Re: [swift-evolution] Warning when omitting default case for imported enums

I like this a lot. +1 Sent from my iPhone > On Feb 7, 2017, at 21:22, Matthew Johnson wrote: > > >> On Feb 7, 2017, at 1:45 PM, Robert Widmann via swift-evolution >> wrote: >> >> I lean +1, but this answer on its own seems incomplete. Exhaustiveness is >> an important property, and it’s n

Re: [swift-evolution] Warning when omitting default case for imported enums

You'd still get the compiler helping you with new cases when working with enums within your module. There's less use in having the compiler help you find new cases when they can only be added between major versions of a package. The benefit to cost ratio here is imbalanced. Enum cases are fore

Re: [swift-evolution] Strings in Swift 4

> On 7 Feb 2017, at 19:44, Dave Abrahams wrote: > > > on Tue Feb 07 2017, "Ted F.A. van Gaalen" wrote: > >>> On 7 Feb 2017, at 05:42, Karl Wagner wrote: >>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution > > wrote: >

Re: [swift-evolution] [Discussion] mailing list alternative

> Believe it or not, not everyone in the world can afford the device and data > plan for a JavaScript-rich web front end (I'm aware of the mobile apps). I > remember only being able to buy an iPod Touch myself when it came out. I > *would* be able to participate SE if it existed back then. Becau

Re: [swift-evolution] Warning when omitting default case for imported enums

Adding a default case when you've exhaustively switched on the enum results in a warning currently. The default case is not really optional at that point if you want to compile without warnings. ``` warning: default will never be executed default: break ``` Sent from my iPhone > On Feb 7, 201

Re: [swift-evolution] Warning when omitting default case for imported enums

The point of the warning is to inform you that the author of the library you depend on could cause your could not to compile by simply adding a case to that enum. This is something you should be happy to avoid as someone writing a library you want other people to depend on or as someone writin

Re: [swift-evolution] Warning when omitting default case for imported enums

I don't understand the part about warning suppression. The warning would go away when you add the default case. Sent from my iPhone > On Feb 7, 2017, at 16:25, Rien wrote: > > -1 > > Reason 1: the “negative” behaviour you describe is actually exactly what I > want to happen. > Reason 2: Int

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 7:54 PM, Tanner Nelson wrote: > > You'd still get the compiler helping you with new cases when working with > enums within your module. That's my point. My projects usually consist of several modules, as I've noted and I don't need to extend the enum from the other modul

Re: [swift-evolution] Strings in Swift 4

> On Feb 7, 2017, at 1:19 PM, Ted F.A. van Gaalen > wrote: > >> >> That proves nothing, though. The fact that people are using integers to >> do this doesn't mean you need to use them, nor does it mean that you'll >> get the right results from doing so. Typically

Re: [swift-evolution] Warning when omitting default case for imported enums

I can assure you that I most definitely do not want an API developer adding to an exposed enum without me -the user- noticing it. That would imo be a recipe for disaster. Regards, Rien. > On 7 Feb 2017, at 19:58, Tanner Nelson wrote: > > The point of the warning is to inform you that the aut

Re: [swift-evolution] Warning when omitting default case for imported enums

BTW, this will likely be part of the eventual design of “open”/resilient enums ala https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums. There, the goal is to reduce both ABI and source breakage caused by this sort of thing. It seems like for your purposes, you’re less incl

Re: [swift-evolution] Allow ' in variable/constant names?

So yeah, solution is to make characters easier to type, not modify the language. +1 to that: what about having editors which provide a graphical access to such characters just as LaTeX editors give access to maths symbols and some functions? The equation editors of other softwares (e.g. recent MS

Re: [swift-evolution] Proposal to improve C pointer type import

Hi Charlie, Thanks for your answer. > Le 7 févr. 2017 à 18:23, Charlie Monroe a écrit : > >> >> On Feb 7, 2017, at 5:56 PM, Florent Bruneau via swift-evolution >> wrote: >> >> Anyone interested in that subject? >> >>> Le 31 janv. 2017 à 09:16, Florent Bruneau via swift-evolution >>> a éc

Re: [swift-evolution] Warning when omitting default case for imported enums

> On Feb 7, 2017, at 1:45 PM, Robert Widmann via swift-evolution > wrote: > > I lean +1, but this answer on its own seems incomplete. Exhaustiveness is an > important property, and it’s not clear what happens here now when you fall > through a “complete” case tree without matching a pattern,

Re: [swift-evolution] Warning when omitting default case for imported enums

I lean +1, but this answer on its own seems incomplete. Exhaustiveness is an important property, and it’s not clear what happens here now when you fall through a “complete” case tree without matching a pattern, and in that sense this plan solves a problem. But it also would hinder a “future-yo

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 This warning suggestion is of highly questionable value. Authors are free to add a default case or not, depending upon the nature of the enum and the logic to handle them. There is no “right” way to suggest, although for high-reliability code, default cases should usually be avoided in my opi

Re: [swift-evolution] [Discussion] mailing list alternative

Turns out it’s possible to retroactively participate a thread that one hasn’t subscribed to. An example of it happening is here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031544.html

Re: [swift-evolution] Warning when omitting default case for imported enums

If you don’t want the default case, and if you like a warning free compilation, you need a way to suppress the warning. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 07 Feb 2017, at 1

Re: [swift-evolution] Strings in Swift 4

on Tue Feb 07 2017, "Ted F.A. van Gaalen" wrote: >> On 7 Feb 2017, at 05:42, Karl Wagner wrote: >> >>> >>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution >>> > wrote: >>> >> When it comes to fast access what’s most important is cache >> l

Re: [swift-evolution] [Discussion] mailing list alternative

I think the arguments about whether Swift is young doesn't really help resolve the argument here. Even an old project would benefit from the best setup to run the community. That to me is what we are discussing here. Let's leave sensational arguments out of it, if we can. I'm not motivated s

Re: [swift-evolution] [Discussion] mailing list alternative

Hi Maxim, This isn't about Apple, this is about how we run the Swift project. This has nothing to do with the default signature in the Mail app on the iPhone. Your question here, while well-intentioned, is as you say super off topic and isn't relevant to both the thread and this mailing list.

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

As long as you don't impose to have at list a space between operators and identifiers you need to be able to split something like a+b into an identifer called "a" followed by an operator "+" itself followed by an identifier "b" In principle we could think of using a way to delimiter an operator n

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

> On Feb 7, 2017, at 7:23 AM, Derrick Ho via swift-evolution > wrote: > > I have found it strange that operator characters are the only ones that may > be used as operators. Sometimes Characters that look like operators are not. > > Why does there need to be a divide? My understanding - 1. l

Re: [swift-evolution] Proposal to improve C pointer type import

> On Feb 7, 2017, at 5:56 PM, Florent Bruneau via swift-evolution > wrote: > > Anyone interested in that subject? > >> Le 31 janv. 2017 à 09:16, Florent Bruneau via swift-evolution >> a écrit : >> >> Hi swift-evolution, >> >> For the last few weeks, I've been working on introducing some S

Re: [swift-evolution] Partial Ranges (was: Strings in Swift 4)

>> Oh, sorry, I was referring to an earlier post I made in this thread, >> but didn’t make that clear. I’ll give a longer explanation of my >> reasoning behind the statement that partial ranges shouldn’t conform >> to Sequence (on their own) below... but the short version is that the >> conforman

Re: [swift-evolution] Proposal to improve C pointer type import

Anyone interested in that subject? > Le 31 janv. 2017 à 09:16, Florent Bruneau via swift-evolution > a écrit : > > Hi swift-evolution, > > For the last few weeks, I've been working on introducing some Swift in a > pure-C codebase. While the Clang importer makes the process quite smooth, > t

Re: [swift-evolution] [Discussion] mailing list alternative

Very sensational arguments. I agree with email is and Swift is young. Not sure that's a real reason to ditch email, however 😀. In fact, I could say *because* email is so old, everything about it has become mature and reliable. Besides great, customized clients, it's also a lower requirement for

Re: [swift-evolution] Strings in Swift 4

Thanks ..seeing now all this being heavily intertwined with external libs ICU etc. then yes, too much effort for too little (making fixed width Unicode strings) Why am i doing this? Unicode is a wasp nest, how do you survive, Dave ? :o) But I do use “random string access" e.g. extracting substr

Re: [swift-evolution] Strings in Swift 4

> On 7 Feb 2017, at 05:42, Karl Wagner wrote: > >> >> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On 6 Feb 2017, at 19:10, David Waite >> > wrote: >>> On Feb 6, 2017,

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 Reason 1: the “negative” behaviour you describe is actually exactly what I want to happen. Reason 2: Introducing a warning would also necessitate a warning suppression in order to have your code compile without warnings. But when you suppress, the purpose of the warning is nul and void. PS:

Re: [swift-evolution] Warning when omitting default case for imported enums

-1 Not having the default case allows you to rely on the compiler to handle new options once they are added. Most of my apps consist nowadays from multiple modules and this would be massively inconvenient. The possible future features may be non-breaking if we consider that we will not allow e

[swift-evolution] Warning when omitting default case for imported enums

Hello Swift Evolution, I'd like to propose that a warning be emitted when default cases are omitted for enums from other modules. What this would look like: OtherModule: ``` public enum SomeEnum { case one case two } public let global: SomeEnum = .one ``` executable: ``` import OtherMo

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

> On Feb 6, 2017, at 11:12 PM, Karl Wagner via swift-evolution > wrote: > > >> On 7 Feb 2017, at 06:05, Slava Pestov > > wrote: >> >>> >>> On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> - Nested protoco

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

I have found it strange that operator characters are the only ones that may be used as operators. Sometimes Characters that look like operators are not. Why does there need to be a divide? Why can't an arbitrary set of characters become operator-ized? For example some people would like "and" to

Re: [swift-evolution] [Discussion] mailing list alternative

Ok, super off topic but since it's Apple after all... Email was considered ancient even back at 2007, when the iPhone was lunched and yet someone at Apple decided it was an important enough channel to use it's scale as a promotional channel with the "Sent from my iPhone", this persists to this ver

Re: [swift-evolution] Compile-time generic specialization

Thank you for the explanation, that makes sense. Do you think it makes sense to create a proposal to allow handling of specialized overloads in Swift? I suspect the issues caused by the current behavior: (a) will continue to confuse a lot of people coming from c++; and (b) affects a wider audien

Re: [swift-evolution] [Discussion] mailing list alternative

> I’d encourage those who want web forums to give Mail.app a try. It does a > remarkable job of keeping emails threaded. That doesn't read like we are using the same Mail.app… it's not failing on a regular basis for me, but it's far away from being remarkable (at least not remarkably good). St

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

> On 7 Feb 2017, at 06:18, Slava Pestov wrote: > >> >> On Feb 6, 2017, at 9:12 PM, Karl Wagner > > wrote: >> >> >>> On 7 Feb 2017, at 06:05, Slava Pestov >> > wrote: >>> On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolutio

Re: [swift-evolution] [Discussion] mailing list alternative

I believe it will be prettyhard to find a solution that fits everyone’s workflow and habits considering the size of the community. The chance we have is that communication systems tends to be very flexible nowadays. Can we imagine some way to have multiple supports integrated ? I can see tools l