Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

One major drawback of splitting Coe library, is that despite having a stable ABI, you break the possibility to include binary frameworks inside an application unless they both link on the same version of libswiftCoreDeprecated.dylib (assuming libswiftCoreDeprecated.dylib has not a stable ABI,

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

A question about the new #unknown behavior. Is it intended to be used for error handling too ? Will it be possible to use in catch clause ? > Le 12 janv. 2018 à 02:48, Howard Lovatt via swift-evolution > a écrit : > > Well if you are happy to say removal of a case

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Going that way, we can also deny addition of new members in a struct. Moreover, while you think that only Apple is interested in having binary stability, this is far to be true, and Apple OSes are not the only OS where Swift can be used. > Le 12 janv. 2018 à 02:48, Howard Lovatt via

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Let say you have a module that declare a enum and also declare a function that take that enum as parameter and switch over it. As there is no cross module boundary, the switch don’t require #unknown or any fancy trick to be exhaustive. Now if you remove the case from the enum, any client code

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> Le 10 janv. 2018 à 23:58, Howard Lovatt via swift-evolution > a écrit : > > Two points: > > 1. I like Chris’s suggestion of #unknown and in particular that it is > distinct from default. > > 2. All the discussion is about a framework adding a case, what about

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> Le 6 janv. 2018 à 04:11, Jon Shier via swift-evolution > a écrit : > > At this point I think it might be useful to outline how binary compatibility > works for Objective-C on Apple platforms right now. As an app developer I’m > not intimately familiar with what

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> Le 28 déc. 2017 à 21:17, Eneko Alonso via swift-evolution > a écrit : > > Hello everyone, > > My name is Eneko Alonso, iOS developer, new here on the list. > > Is there a good summary anywhere that condenses the pros and cons of this new > feature that have

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Look like we don’t know the same users. I don’t know a single user that didn’t update it’s device at least once since he bought it, even if some may avoid the latest update when there device grow old though. > Le 25 déc. 2017 à 05:46, Kelvin Ma via swift-evolution >

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution > a écrit : > > > >> On 07 Dec 2017, at 22:26, Chris Lattner > > wrote: >> >>> >>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez a écrit : > > > > On Dec 2, 2017, at 11:46 PM, Jean-Daniel > wrote: > >> >> >>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution >>>

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> … > Beyond that, it is counterproductive to your goals, because it means that > people are far less likely to use to use optional returns. Doing so (which > produces a safer result) would cause a double tax in syntax, and would be a > confusing jumble. I can’t bring myself to do the whole

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution > a écrit : > > Hi Chis, > > Thank you for pushing this forward. > > My only comment is that on the declaration side it would be great to also > have an attribute to communicate that compiler magic

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Le 28 nov. 2017 à 22:56, Ben Rimmington via swift-evolution > a écrit : > > I suggest using different subscripts for function/method calls and properties: > While I perfectly understand why subscript is the best way to represent dynamic property, I don’t get

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> … > > In Ruby, `myObj.name()` is equivalent to `myObj.name`, and either works. In > Swift, I don’t see that it’s possible to make both work with Chris’s proposal. IIUC, the goal is not to make swift look and behave the same as ruby or python, but to be able to use ruby or python object in a

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> > Here's a variety of possible new names, in descending order of personal > preference: > > mapUnwrappingSome > mapAndUnwrap // Thanks Nevin, this is surprisingly clear. > mapUnwrapSome > mapUnwrapIfSome > mapSome // For these last three, it's unclear when nil elements are >

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

> Le 16 nov. 2017 à 07:00, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution >> > wrote: >> >> extension PyVal { >>

Re: [swift-evolution] [Pitch] Introduce User-defined "Dynamic Member Lookup" Types

Just a question about what it mean for API resilience. Actually, adding a property to an existing class is not a breaking change. For a class that implements that protocol, as it will be possible to use property accessor with any non existing property. Adding a new property to this class

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> Le 15 oct. 2017 à 15:52, Mike Kluev via swift-evolution > a écrit : > > On 15 October 2017 at 14:23, Geordie Jay > wrote: > Hi Mike, > > 2017-10-15 14:55 GMT+02:00 Mike Kluev

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

> Le 13 oct. 2017 à 23:23, Mike Kluev via swift-evolution > a écrit : > > On 13 October 2017 at 21:15, Jean-Daniel > wrote: > I don’t think this is a good idea to make discardable part of the function > type. >

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

I don’t think this is a good idea to make discardable part of the function type. What would fun(callback: () -> discardable Int) would means ? And allowing it in signature but not in lambda would be confusing. > Le 12 oct. 2017 à 15:32, Mike Kluev via swift-evolution >

Re: [swift-evolution] Question about async await

> Le 26 sept. 2017 à 22:38, Pierre Habouzit <phabou...@apple.com> a écrit : > >> On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> Le 26

Re: [swift-evolution] Question about async await

> Le 26 sept. 2017 à 00:13, Adam Kemp <adam_k...@apple.com> a écrit : > > >> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> Le 25 sept. 2017 à 21:42, John McCall via swift-ev

Re: [swift-evolution] Question about async await

> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution > <swift-evolution@swift.org> a écrit : > >> On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] Question about async await

> Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution > a écrit : > >> >> Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE > > a écrit : >> >> >> Le 25 sept. 2017 à 11:55, Thomas

Re: [swift-evolution] Question about async await

> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution > a écrit : > > >> Le 20 sept. 2017 à 21:15, Jean-Daniel > > a écrit : >> >> >> >>> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via

Re: [swift-evolution] Question about async await

> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution > a écrit : > >> >> Le 18 sept. 2017 à 18:07, Pierre Habouzit > > a écrit : >> >> >> -Pierre >> >>> On Sep 18, 2017, at 2:04 AM, Trevör Anne

Re: [swift-evolution] [Proposal] Random Unification

> Le 9 sept. 2017 à 21:03, Taylor Swift via swift-evolution > a écrit : > > > > On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution > > wrote: > On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon

Re: [swift-evolution] [Proposal] Random Unification

> Le 9 sept. 2017 à 03:07, Xiaodi Wu via swift-evolution > a écrit : > > On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon > wrote: >> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [Concurrency] async/await + actors

> Le 4 sept. 2017 à 17:54, Chris Lattner via swift-evolution > a écrit : > > On Sep 4, 2017, at 4:19 AM, Daniel Vollmer > wrote: >> >> Hello, >> >> first off, I’m following this discussion with great interest, even though

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> Le 28 août 2017 à 06:14, Howard Lovatt via swift-evolution > a écrit : > > One of the biggest incumbents in this space on the server side is Java and > its concurrency is based on futures and works very well (though there are a > lot of libraries built on top of

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> Le 26 août 2017 à 07:27, Howard Lovatt via swift-evolution > a écrit : > > My argument goes like this: > > 1. You don't need async/await to write a powerful future type; you can use > the underlying threads just as well, i.e. future with async/await is no >

Re: [swift-evolution] Two thoughts on concurrency

> Le 24 août 2017 à 22:59, Dave DeLong via swift-evolution > a écrit : > > Hi everyone, > > (the standard disclaimer of “I’m neither a compiler engineer nor a language > design expert” applies) > > I’ve been trying to keep up with all the discussion around

Re: [swift-evolution] (core library) modern URL types

Yes, and a URI class that don’t provide any FS operations, but only take care of proper URI parsing and building. > Le 23 août 2017 à 12:03, Jakob Egger via swift-evolution > a écrit : > > I would absolutely love to see an API like AbsolutePath / RelativePath for >

Re: [swift-evolution] Swift 5: start your engines

> Le 9 août 2017 à 00:06, Erica Sadun via swift-evolution > a écrit : > > >> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution >> > wrote: >> >> Perhaps I am too optimistic, and core team

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution > a écrit : > >> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution >> > wrote: >> >> Hello, >> >>> On 30. Jul 2017, at 08:52,

Re: [swift-evolution] SE-0181 : should c++ be written "cxx" or "cpp" ?

Le 13 juil. 2017 à 00:59, Chris Lattner via swift-evolution a écrit :On Jul 12, 2017, at 2:21 PM, Greg Parker via swift-evolution wrote:On Jul 12, 2017, at 10:21 AM, Trevör ANNE DENISE via swift-evolution

Re: [swift-evolution] Idea: Use for default implementation of ?

If we generate a default• debugDescription for encodable type, I would rather use a human readable formatted string that explicitly do not guarantee to remain stable. JSON is very limited in the types it supports (it does not even supports date natively). A debug description should not

Re: [swift-evolution] Yet another fixed-size array spitball session

> Le 31 mai 2017 à 01:47, Anders Kierulf <and...@smartgo.com> a écrit : > >> >> On May 30, 2017, at 3:36 PM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >&

Re: [swift-evolution] Yet another fixed-size array spitball session

> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution > a écrit : > > There was someone a few weeks ago trying to port his Go game to Swift from (I > believe) C++ and found out that the lack of fixed-size arrays was causing the > move-computing algorithm to

Re: [swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution > a écrit : > > >> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution >> > wrote: >> >> >>> On May 6, 2017, at 1:11 PM, Félix

Re: [swift-evolution] Replace throws with Result

> Le 3 mai 2017 à 16:12, Jose Manuel Sánchez Peñarroja via swift-evolution > a écrit : > >> At what cost ? Today, the error handling is barely zero-cost thanks to the >> swift calling convention. Having a generic return type will not only prevent >> calling

Re: [swift-evolution] Replace throws with Result

> Le 3 mai 2017 à 12:06, Jose Manuel Sánchez Peñarroja via swift-evolution > a écrit : > > There is currently a discussion open about throws, but it seems that the idea > would be to add optionals to throws. In my opinion it would be much better to > just get rid

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I’m full -1 on this one. It will make the language inconsistent. How do you explain a new comer that type inference work in some case, but not in other cases, while in both the compiler is completely capable to define the type. Why let myString = "hello" would be accepted but not class

Re: [swift-evolution] Enhancing access levels without breaking changes

> Le 10 avr. 2017 à 07:15, David Hart via swift-evolution > a écrit : > > > > On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution > > wrote: > >> >>> On Apr 9, 2017, at 7:14 PM, Jonathan

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

So, +1 for me too. I’m part of the people who didn’t want SE-0025 in the first place, and don’t like any workaround we try to implement to mitigate it, but taking the Core Team decision in account, I feel this is the right thing to do now. If strong scoped variables are needed, it will always

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> Le 7 avr. 2017 à 03:53, Brent Royal-Gordon via swift-evolution > a écrit : > >> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu

Re: [swift-evolution] Pitch: @objc attribute for top-level functions

> Le 1 avr. 2017 à 00:53, Joe Groff via swift-evolution > a écrit : > >> >> On Mar 31, 2017, at 8:00 AM, Charles Srstka via swift-evolution >> wrote: >> >> MOTIVATION: >> >> Sometimes, it’s necessary to write a top-level C function in

Re: [swift-evolution] Remove prefixes from all Apple frameworks

Not only with your own code. There is so many Apple Framework, I’m pretty sure it won’t be difficult to find conflicting class name. > Le 31 mars 2017 à 08:02, Rien via swift-evolution > a écrit : > > The problem with unprefixed names is name clashes with my own

Re: [swift-evolution] [Pitch] String revision proposal #1

I’m with you for a C intro API that support taking a non-null terminated string. I often work with API that support efficient parsing by providing pointer to a global buffer + length to report parsed strings. Without a way to create a Swift string from buffer + length, interop with such API

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

> Le 24 mars 2017 à 18:28, Jeff Kelley via swift-evolution > a écrit : > > One of the things that struck me from today’s Apple press release about Swift > Playgrounds being localized in more languages is this screenshot: > > > > All of the UI is fully localized

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> Le 24 mars 2017 à 09:10, Charlie Monroe <char...@charliemonroe.net> a écrit : > >> >> On Mar 24, 2017, at 8:20 AM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >&g

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution > a écrit : > >> >> On Mar 23, 2017, at 9:03 AM, Charlie Monroe > > wrote: >> >>> >>> On Mar 23, 2017, at 9:44 AM, Slava Pestov

Re: [swift-evolution] [Proposal] Factory Initializers

> Le 21 mars 2017 à 22:09, Jonathan Hull via swift-evolution > a écrit : > > There are several reasons. It is a very common pattern in ObjC/Cocoa. For > example, they allow class clusters (and the protocol equivalent). I don’t see that as a strong argument for

Re: [swift-evolution] Smart KeyPaths

> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution > a écrit : > > I agree that they can get mixed up with static properties. However, I think I > would not mind because it would only cause an ambiguity when having a static > property with the same name

Re: [swift-evolution] Inefficiency in recursive value types

If you want to understand the performance implication of using protocol for value type, you should watch this session. https://developer.apple.com/videos/play/wwdc2016/416/ It is very instructive. > Le 13 mars 2017 à 13:55, Dimitri

Re: [swift-evolution] Infer types of default function parameters

-1 It would be inconsistent to allow it for deterministic literals (String) and not for non deterministic literal (int which can be either a Int, Uint, Float, …) > Le 10 mars 2017 à 22:40, Kilian Koeltzsch via swift-evolution > a écrit : > > Hi all, > > I sent

Re: [swift-evolution] [Draft] Fix Private Access Levels

> Le 6 mars 2017 à 19:27, Nevin Brackett-Rozinsky via swift-evolution > a écrit : > > I support this proposal to restore the file-based meaning of “private”. > > Personally, I do not think we need any more fine-grained access level than > this, so I lean toward

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> Le 3 mars 2017 à 23:21, Matthew Johnson via swift-evolution > a écrit : > >> >> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution >> wrote: >> >> >> I’ve read through the last couple of Swift (sub)Module proposals put >>

Re: [swift-evolution] Simplifying Access Using 'Hidden'

> Le 15 févr. 2017 à 16:37, Michel Fortin via swift-evolution > a écrit : > >> >> Le 15 févr. 2017 à 9:28, Vladimir.S via swift-evolution >> a écrit : >> >> On 15.02.2017 14:29, Joanna Carter via swift-evolution wrote: The beauty

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 15 févr. 2017 à 08:05, David Hart via swift-evolution > a écrit : > > > > > Sent from my iPhone > On 15 Feb 2017, at 06:31, Chris Lattner > wrote: > >> >>> On Feb 14, 2017, at 3:20 AM, David Hart

Re: [swift-evolution] final + lazy + fileprivate modifiers

t; >> If the overwhelming use case is that developers should pick one over the >> other primarily because it looks nicer, then blindly click the fix-it when >> things stop working, then the distinction between private and fileprivate is >> pretty clearly a mere nuisanc

Re: [swift-evolution] final + lazy + fileprivate modifiers

> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution > a écrit : > > On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution > > wrote: >> Final >> Can someone tell me what is the use of

Re: [swift-evolution] Is it possible to compile swift code to dynamic library ?

This is what Xcode do when it build a framework. Note that your application while have to link on the Swift runtime though. > Le 9 févr. 2017 à 07:53, Zheng Ping via swift-evolution > a écrit : > > > Compile swift code to dynamic library(a *.so file which is

Re: [swift-evolution] Nil-rejection operator

While I find the concept interesting, I give a big -1 for using the ‘!’ operator for something else that fatal error. > Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution > a écrit : > > Hi all, > > Currently there are a number of different operators for

Re: [swift-evolution] Initializers

> Le 4 févr. 2017 à 16:52, Rod Brown via swift-evolution > a écrit : > > Hi Joe, > > I think this comes back to the idea that a lot of people in the wider Swift > community hold that Implicitly Unwrapped Optionals are “bad” and > “discouraged", and therefore

Re: [swift-evolution] @NSCopying currently does not affect initializers

> Le 28 janv. 2017 à 05:34, Torin Kwok via swift-evolution > a écrit : > > Hello guys, > > Note: This issue has been originally presented in swift-users mailling list > . > And then I

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

> Le 26 janv. 2017 à 00:34, Erica Sadun via swift-evolution > a écrit : > > >> On Jan 25, 2017, at 1:05 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> I have no problem with the project moving to

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> Le 20 janv. 2017 à 22:55, Howard Lovatt via swift-evolution > a écrit : > > In Java there is a hierarchy of errors, the idea is that you catch at > different severities. It isn't particularly well implemented in Java with a > weird hierarchy and errors strangely

Re: [swift-evolution] Strings in Swift 4

> Le 20 janv. 2017 à 05:07, Saagar Jha via swift-evolution > a écrit : > > Looks pretty good in general from my quick glance–at least, it’s much better > than the current situation. I do have a couple of comments and questions, > which I’ve inlined below. > >

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

In your example, you don't prepend the prefix but the whole name (JRKCity), so we don’t need to define what the prefix is. > Le 5 janv. 2017 à 20:13, Jeff Kelley via swift-evolution > a écrit : > > Would that prepend the prefix on individual members? If so that’s

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

An interesting reading about testing private members: https://cocoacasts.com/how-to-unit-test-private-methods-in-swift/ > Le 12 déc. 2016 à 06:10, Derrick Ho via swift-evolution > a écrit : > > It

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Le 1 déc. 2016 à 18:54, Gonçalo Alvarez Peixoto via swift-evolution > a écrit : > > @Aron, I did take a look at that document while developing the proposal. As > you stated, it's a little old, however the principles of access control and > their purpose remain

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

Of course, I meaned set(newValue foo: valueType) { } > Le 4 déc. 2016 à 09:56, Jean-Daniel via swift-evolution > <swift-evolution@swift.org> a écrit : > > If you want to go to the side of consistency, why not just require the > standard method syntax like any other

Re: [swift-evolution] [Pitch] Removing Setter/Observer Name Overrides

If you want to go to the side of consistency, why not just require the standard method syntax like any other place ? set(foo newValue: valueType) { } So old/newValue will become a parameter label. > Le 4 déc. 2016 à 04:06, Erica Sadun via swift-evolution > a

Re: [swift-evolution] Swift evolution proposal: introduce typeprivate access control level

> Le 30 nov. 2016 à 16:00, João David via swift-evolution > a écrit : > > Definetely the access control topic is highly contestable in the Swift scene > but nevertheless I really strive for more flexibility in terms of how can I > decouple and decompose my code

Re: [swift-evolution] Global init() functions

> Le 19 nov. 2016 à 15:58, Alan Cabrera via swift-evolution > a écrit : > > I’m not sure if this was proposed or not; or even if this is a Swift-ly way > of doing things. It would be pretty handy to be able to declare init() > functions in my module to register

Re: [swift-evolution] [Proposal] Type Narrowing

> Le 14 nov. 2016 à 10:10, Haravikk <swift-evolut...@haravikk.me> a écrit : > > >> On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&

Re: [swift-evolution] [Proposal] Type Narrowing

> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution > a écrit : > > That's a good point in Jay's example and from what I can tell a good way to > address it, Haravikk. > > I've done some work in a language that only provides type narrowing for >

Re: [swift-evolution] [Proposal] Type Narrowing

> Le 7 nov. 2016 à 04:52, Chris Lattner via swift-evolution > a écrit : > > >> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution >> wrote: >> >> To avoid hijacking the guard let x = x thread entirely I've decided to try >> to

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

> Le 20 oct. 2016 à 02:11, Xiaodi Wu via swift-evolution > a écrit : > > I actually take the opposite view of emoji, and I was convinced of this by > arguments from some of the other authors (though they may not come to the > same conclusions as I do): > > The

Re: [swift-evolution] [Pitch] Ban the top value in Int/UInt

> Le 18 oct. 2016 à 21:09, Charlie Monroe via swift-evolution > a écrit : > > Talking about bridging - my guess is that it would mess with NSNotFound which > still has legit use cases even in Swift (when dealing with ObjC APIs) and is > defined as NSIntegerMax at

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

> Le 17 oct. 2016 à 23:20, Max Moiseev via swift-evolution > a écrit : > > Hi Louis, > > I believe, sometimes there are situations where you know for sure that your > collection is not empty. Maybe you are already in the context where the check > has been

Re: [swift-evolution] private & fileprivate

> Le 13 oct. 2016 à 23:27, Ted F.A. van Gaalen a écrit : > > Please do NOT drop the current distinction between *private* and *fileprivate* > as it is now in Swift 3 > It is needed for correct OOP. > That argument don’t apply for a language where you can structure

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

> Le 13 sept. 2016 à 01:48, Greg Parker via swift-evolution > a écrit : > > >> On Sep 12, 2016, at 3:39 PM, Douglas Gregor > > wrote: >> >> As an amendment to SE-0140, Swift will produce a warning when an optional >>