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

I don't have much non-nitpick issues that I greatly care about; I'm in favor of this. My only request: it's currently painful to create a String from a fixed-size C array. For instance, if I have a pointer to a `struct foo { char name[16]; }` in Swift where the last character doesn't have to be

Re: [swift-evolution] (Pitch) Conformance Regions

What will you do if you want to privately adopt two protocols that require identical members? Also, you write that you want to be able to write members into extensions but you can't. Have you considered pushing to make it possible? > Le 30 mars 2017 à 10:07, Ross O'Brien via swift-evolution >

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

e 30 mars 2017 à 17:27, Zach Waldowski via swift-evolution > a écrit : > > On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote: >> I don't have much non-nitpick issues that I greatly care about; I'm in favor >> of this. >> >>

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

During the proposal phase, we asked how this would handle fixed-length strings with an optional NUL terminator. For instance, in a C `struct Foo { char name[8]; };`, `name` stops at the first \0, or at the eighth byte, whichever comes first. IIRC, Ben said that it would be handled, but I'd like

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

It probably depends on the positioning of the initializer. I strongly associate the collection initializer to the special case of UnsafeBufferPointer, and the result strings will probably be passed back to C at some point, where an embedded NUL terminates the string (inconsistently with what Swi

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> What is your evaluation of the proposal? -1, approximately. > Is the problem being addressed significant enough to warrant a change to > Swift? I don't necessarily think that the concept is a bad idea, but I think that the interaction of Swift features facilitates poor coding decisions. For

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

To be clear, I don't think that it's a particularly powerful footgun. It's just perpetuating the unfortunate status quo on injection vulnerabilities. C# was able to eliminate the whole class of SQL injections by introducing a convenient and powerful syntax for queries that is not string-based. I

Re: [swift-evolution] [pitch] One-sided Ranges

I don't have a strong opinion; are we sure enough that this is what we want the postfix operator … to be for? For instance, C++ uses it a lot with variadic templates. > Le 12 avr. 2017 à 13:21, David Hart via swift-evolution > a écrit : > > I remember being against this feature when it was fi

Re: [swift-evolution] [pitch] One-sided Ranges

ris a écrit : > > >> On Apr 12, 2017, at 20:31, Félix Cloutier via swift-evolution >> wrote: >> >> I don't have a strong opinion; are we sure enough that this is what we want >> the postfix operator … to be for? For instance, C++ uses it a lot with &

Re: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

Why? > Le 4 mai 2017 à 19:14, Robert Widmann via swift-evolution > a écrit : > > Hi all, > > So sorry that this proposal comes so late in the game, but I feel it’s too > important not to bring it to the attention of the community now. Attached is > a proposal to deprecate a language feature

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

I have one concern and one general comment. General comment: there's a switch to turn off overflow checks for performance reasons. It seems to me that this check is going to be much more expensive than an overflow check, and it's certainly not much more likely to trigger in a release build afte

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

ai 2017 à 10:36, John McCall a écrit : > >> >> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I have one concern and one general comment. >> >> General comment: there's a

Re: [swift-evolution] [pitch] Character.unicodeScalars

+1. > Le 10 mai 2017 à 16:51, Ben Cohen via swift-evolution > a écrit : > > Hi swift-evolution, > > A short string-related pitch for you. > > > Add unicodeScalars property to Character > > Proposal: SE- > > Authors: Ben Cohen > Review Manager: TBD >

Re: [swift-evolution] Int indexing into UTF16View

It's not. Static strings use UTF-8. > Le 8 juin 2017 à 16:38, David Hart via swift-evolution > a écrit : > > > >> On 8 Jun 2017, at 14:15, Vladimir.S wrote: >> >>> On 08.06.2017 20:32, David Hart via swift-evolution wrote: >>> Hello, >>> When working with Strings which are known to be ASCII

Re: [swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?

How should the fix-it transform the following code to make it valid? func foo(bar: String) -> Int func frob() -> String? func qaz() -> Int { return foo(bar: frob()) // frob() is optional, insert a ! to fix } > Le 13 juil. 2017 à 21:36, Robert Bennett via swift-evolution > a écrit : >

Re: [swift-evolution] Xcode Fix-It action for returning closures

AFAIK, fix-it is driven by the Swift compiler/source kit. > Le 13 juil. 2017 à 23:17, Saagar Jha via swift-evolution > a écrit : > > You should probably file a Radar for this, since Xcode isn’t part of the > Swift project. > > Saagar Jha > >> On Jul 13, 2017, at 19:46, iCloud via swift-evolu

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

I think that you're getting ahead of yourself. Fixed-size arrays are still useful even if they have to have been demonstrably initialized before you can use dynamic indices with them. A ton of people have already gotten into the habit of writing `int foo[40] = {}` in C. I would like to encourag

Re: [swift-evolution] [Pre-pitch] "common" fields for union-style enumerations?

AFAIK, you can legally access the compatible prefix of structure fields in C. (Regardless of whether you have a pointer to a Sample1 or to a Sample2, casting it to either and accessing a or b is guaranteed to work; c or d is UB.)

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

I think I've already said that, but I agree that an incremental approach to this would be better. > Le 23 juil. 2017 à 15:57, Chris Lattner a écrit : > > On Jul 22, 2017, at 3:03 PM, Daryle Walker wrote: >>> In my opinion, there is an easy three step plan :-) to solving this >>> problem, riff

Re: [swift-evolution] [Pitch] New Version of Array Proposal

It is not good enough for C interop because a design where the element count is data rather than part of the type cannot be layout-compatible with a C fixed-size array. Félix > Le 23 juil. 2017 à 22:22, Charles Srstka via swift-evolution > a écrit : > > Do FSAs really need special sugar, tho

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

The mere virtue of a strong typealias won't provide an implementation of the Sequence protocol, and as was just established, the language isn't equipped to provide an automatic implementation through the standard library. Your suggestion is an entry point for compiler magic. If we get into that

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> parameters, "let fsa = FSA(whateverArgs) //where `Count` is an > integer literal, or some other integer value that can be determined at > compile time". > > - Dave Sweeris > > On Jul 24, 2017, at 1:05 AM, Félix Cloutier via swift-evolution > mailto:swift

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> Le 24 juil. 2017 à 10:43, Tino Heth <2...@gmx.de> a écrit : > > >> The last point is especially worrying to me because things like non-type >> generic parameters are *much bigger* than fixed-size arrays. > > Why do you think that's the case? This is a bit of a naive thing to say since we do

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

Right now, it's marked as "maybe" in the generic manifesto . > There are a number of features that get discussed from time-to-time, while > they could fit into Swift's generics system, it's not clear t

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> Le 29 juil. 2017 à 16:01, Daryle Walker a écrit : > > >> On Jul 25, 2017, at 2:14 AM, Félix Cloutier via swift-evolution >> wrote: >> >> It seems to me that I'm the one advocating for fewer language changes, and >> the majority of sub-featu

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

It seems to me that this applies just the same to type generic parameters. Are there any reason that you can't instantiate a generic type at runtime, or is it just because the need is not as evident as it would/could be with non-type generic parameters? > Le 30 juil. 2017 à 21:10, John McCall v

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

> Le 31 juil. 2017 à 00:40, Xiaodi Wu via swift-evolution > a écrit : > > > On Mon, Jul 31, 2017 at 02:15 Gor Gyolchanyan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution > > mailto:swift-evolution@swift.org>> wr

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

> Sure, and hence my point: suppose now `foo` is a function in the stdlib, and > the stdlib authors have annotated the function so that it is `func foo(arr: > fixed [Int])`. Then, any user who writes `var array = ...` could benefit from > a performance boost because the compiler will not longer

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

No, this is a misunderstanding: I mean "you" as yourself, not "you" as the compiler. As far as I know, given a type variable, as in `let foo: NSObject.Type = NSArray.self`, you (the developer) can't use `foo` to instantiate a generic type. The question stands again: are there any specific reaso

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

> Le 31 juil. 2017 à 18:54, Xiaodi Wu a écrit : > It doesn't allow you to specify the size of the array, it's just a promise > that the array is some immutable size. For instance, a `fixed [CGFloat]` > would be a terrible type to represent a vector, but a FixedSizeArray 4> would be appropriate,

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

`[Int x N]` solves all of the problems that I mentioned, and I'm happy with that syntax. In fact, I'm championing its merits versus an approach that doesn't include the number of elements. :) Unless I got things wrong this entire time, the proposed spelling

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

> Le 3 août 2017 à 17:44, Taylor Swift via swift-evolution > a écrit : > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >>> >>> The root cause, of course, is that the VLAs require new stack allocations >>> each time, and the stac

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

As far as I can tell, currently, all arrays live on the heap. > Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution > a écrit : > > Where do constant Arrays currently live? I hope the answer is on the stack, > since their size doesn’t change. > > On Aug 3, 2017, at 8:44 PM, Taylor Swif

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

s live on the stack? > >> On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> As far as I can tell, currently, all arrays live on the heap. >> >>> Le 3 août 2017 à 19:03, Robert Bennett

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

tion details of Swift, so I may be way off base here. > >> On Aug 4, 2017, at 2:18 AM, David Hart > <mailto:da...@hartbit.com>> wrote: >> >> Don’t small arrays live on the stack? >> >>> On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution >

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

> Le 4 août 2017 à 11:39, Robert Bennett a écrit : > >> That's not a concern with the `let` case that Robert brought up, since you >> can't mutate a `let` array at all. >> >> The big thing is that unconstrained escape analysis is uncomputable. Since >> Swift array storage is COW, any function

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

> Le 6 août 2017 à 08:15, Karl Wagner a écrit : > >> >> On 4. Aug 2017, at 20:15, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-e

Re: [swift-evolution] How does "Sequence.joined" work?

All this means is that `joined()` does not create an array that contains the new result. It's only as magic as the COW semantics on arrays. > Le 7 août 2017 à 21:12, Daryle Walker via swift-evolution > a écrit : > > I was looking at random items at SwiftDoc.org , and > n

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I'm going to separate your examples into FooStruct and FooProtocol for clarity. I agree that generics tend to propagate virally and I remember that at some point I wanted type erasure, though I don't remember for what exactly. The solution for `sayHi`, right now, is to make that one generic too:

Re: [swift-evolution] How does "Sequence.joined" work?

Yes, exactly. An Array is a struct wrapper for a reference type representing storage. Mutating functions first check if they own the only reference to the storage using isKnownUniquelyReferenced . If not, they ma

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

us...@swift.org>> wrote: > > > On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Yes, exactly. An Array is a struct wrapper for a reference type > representing storage. Mutating functions first c

Re: [swift-evolution] [discussion] SPI?

Could you clarify? What do you hope to achieve beyond access/visibility control? > Le 14 août 2017 à 07:19, Mathew Huusko V via swift-evolution > a écrit : > > Curious if SPI access/visibility control has been discussed/planned? I know > the standard access control debate is long past, but thi

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

I'm glad to see this moving forward. I have a few questions and comments. First, I'd like it if someone could clarify for me what beginAsync and suspendAsync "actually do", and how they interact with `async` functions. I'm throwing a lot of good will at this but my brain is still fairly imperat

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

I'm not convinced that URLs are the appropriate abstraction for a file system path. For the record, I'm not a fan of existing Foundation methods that create objects from an URL. There is a useful and fundamental difference between a local path and a remote path, and conflating the two has been a

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

There's no question that there's a lot in common between file: URLs and other URLs, but that hardly makes URLs better in the file: case. I saw the enum. The problem remains that it's a common API principle to accept the broadest possible input. It's not fundamentally wrong to accept and resolve

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

, at 11:24 AM, Félix Cloutier via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> There's no question that there's a lot in common between file: URLs and >> other URLs, but that hardly makes URLs better in the file: case. >> >> I saw t

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

Alternatively, until futures are a thing, you can call `beginAsync` twice to start to async tasks: func process() -> Void { beginAsync { let dataResource = await loadWebResource("bigData.txt") // } print("BigData Scheduled to lo

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

sn’t handle pure-relative paths very well, and it’s always a bit of a mystery how resilient I need to be about checking .isFileURL or whatever. All the extra properties (port, user, password, host) feel hugely unnecessary as well. Dave On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-ev

Re: [swift-evolution] Two thoughts on concurrency

I feel that it's important to point out that this example feels weird because even though the compiler doesn't treat "weak" as a reserved term, most developers perceive it as one. I don't think that David is worried that we're taking away all the cool words from the realm of identifiers; the pro

Re: [swift-evolution] await keyword "scope"

I don't believe that having "await" everywhere will remind you that you have to precalculate and cache operands to suspending operations. In fact, it sounds like your goal is not to enforce that every async operation is gated behind `await`, but to ensure that developers cache the operands of as

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

If all the hard symbols are automatically converted by the editor, why can't the editor show you a "pretty" view and save as "regular" text? Why does it need compiler involvement if the problem can entirely be addressed in UI space? > Le 29 août 2017 à 06:14, John Pratt via swift-evolution > a

[swift-evolution] Figuring out what you get for free

If you look at the source for Sequence , you can see that the protocol declares a ton of methods and properties; but in fact, all you need to provide is Element, Iterator and makeIterator. The rest comes for free

Re: [swift-evolution] Problems with generics - should be fixed for Xcode 9?

I always thought that this was a bug, but I can't find it on bugs.swift.org, so I'd love to know if it's meant to stay this way or not. > Le 16 sept. 2017 à 06:32, Joanna Carter via swift-evolution > a écrit : > > Greetings > > Old chestnut, sort of partially solved but still problems. > > N

Re: [swift-evolution] Figuring out what you get for free

I found that for Sequence, but Sequence is far from the only protocol with default implementations, and not all of them have maintainers willing to write and update documentation to the degree that Apple will. Félix > Le 14 sept. 2017 à 15:10, Kyle Murray a écrit : > > >> However, I find tha

Re: [swift-evolution] Figuring out what you get for free

To be clear, I find the stdlib already fairly well-documented. I think that the problem is more important for types from projects that are unlikely to get good documentation. > Le 17 sept. 2017 à 23:43, Dimitri Racordon via swift-evolution > a écrit : > >> - In step 2, the compiler could prop

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Another alternative is to use `array = array.filter { $0 != someElement }`. I thought that there would be a `remove(where:)` method, but there isn't. Félix > Le 25 sept. 2017 à 02:12, Alwyn Concessao via swift-evolution > a écrit : > > Hello, > > After going through the Swift standard librar

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

gonomic--with any luck, some better names for > existing extension methods and filling in a very few gaps judiciously would > allow us to make the existing facilities sufficiently more discoverable that > it will be easier to accomplish what you seek without adding more extensions. >

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

ry few gaps judiciously would >> allow us to make the existing facilities sufficiently more discoverable that >> it will be easier to accomplish what you seek without adding more extensions. >> >> >> On Mon, Sep 25, 2017 at 11:14 Félix Cloutier via swift-evolution >> m

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

I'm okay with "unqualified" random being crypto-secure and qualifying non-crypto-secure generators as inferior, but I think that Unsafe is not the qualifier we are looking for. Everywhere else, Unsafe implies that misuse will cause unpredictable results/crashes, which is a different class of pro

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

> Le 26 sept. 2017 à 07:31, Xiaodi Wu via swift-evolution > a écrit : > > * The distinction to be made here is CSPRNGs versus non-cryptographically > secure PRNGs, where CSPRNG : PRNG. “Reproducible” is not the right word. > Based on my understanding, some CSPRNGs can be “reproducible” if th

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

> Le 26 sept. 2017 à 16:14, Xiaodi Wu a écrit : > > On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier > wrote: > > It's possible to use a CSPRNG-grade algorithm and seed it once to get a > reproducible sequence, but when you use it as a CSPRNG, you typically f

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

> Le 27 sept. 2017 à 17:29, Xiaodi Wu a écrit : > > What I was trying to respond to, by contrast, is the design of a hierarchy of > protocols CSPRNG : PRNG (or, in Alejandro's proposal, UnsafeRandomSource : > RandomSource) and the appropriate APIs to expose on each. This is entirely > inappl

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

> Le 30 sept. 2017 à 08:22, Xiaodi Wu a écrit : > > On Thu, Sep 28, 2017 at 12:16 PM, Félix Cloutier > wrote: > > >> Le 27 sept. 2017 à 17:29, Xiaodi Wu > > a écrit : >> >> What I was trying to respond to, by contrast, is the desig

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

> Le 1 oct. 2017 à 07:24, Xiaodi Wu a écrit : > It seems to me that a CSPRNG interface is useful if you need crypto-secure > random numbers, but you can trust input from sources that don't come with the > guarantees of the global CSPRNG, and from algorithms that you can't > exhaustively list

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

If you tried hard enough, you could probably create a variable that looks like it's shadowing one from an outer scope while it actually isn't, and use the two to confuse readers. This could trick people into thinking that some dangerous/backdoor code is actually good and safe, especially in the

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> Le 2 oct. 2017 à 21:40, Chris Lattner a écrit : > >> On Oct 2, 2017, at 1:13 AM, Félix Cloutier via swift-evolution >> wrote: >> >> If you tried hard enough, you could probably create a variable that looks >> like it's shadowing one from an out

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

I'm really not enthusiastic about `random() -> Self?` or `random() throws -> Self` when the only possible error is that some global object hasn't been initialized. The idea of having `random` straight on integers and floats and collections was to provide a simple interface, but using a global C

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

Anything that hasn't killed the process seems fine, and you have to start from `main` for anything else. On iOS, you can be suspended at any time, but the program will only continue from the point that it was suspended if it hasn't been torn down; otherwise, it has to restart from the beginning

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

> Le 4 oct. 2017 à 19:26, Xiaodi Wu via swift-evolution > a écrit : > To sum up my thoughts so far in code, building on previous comments from > others, this would be a nice set of random APIs, IMO: > > ``` > extension Int { > static func random(in range: Countable{Closed}Range) -> Int > }

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

I agree that as an operation, .randomElement() feels closer to .first and .last (check that there's an element in the collection) than to the subscript (trap). However, it *is* a usability sore spot on collection literals and ranges made from literals. Nobody writes [1,2,3].first, because the fi

Re: [swift-evolution] Opaque Pointers in Swift

Could you do a conditional typealias? #if OPENSSL_HAS_OPAQUE_POINTERS typealias OpenSSLContext = OpaquePointer #else typealias OpenSSLContext = UnsafeMutablePointer #endif Then as long as you don't need to build one single OpenSSL that supports both, you'll be fine (although it might work anyway

Re: [swift-evolution] Ad hoc enums / options

I like the idea, but it is worth noting that unless the syntax is generalized (which I'm not necessarily against), the type of `operation` cannot be referenced. This means that you can't declare a variable of that type, unless you assign the argument to it. Félix > Le 31 mai 2016 à 09:16:56, E

Re: [swift-evolution] Ad hoc enums / options

What if (.Fit | .Fill) was just a shorthand for enums that you could use anywhere, like a tuple type? let foo: (.Fit | .Fill) = .Fit let bar: (.Fit | .Fill) = .Fill let frob = cond ? foo : bar // foo and bar have the same type You could typealias it too. Félix > Le 1 juin 2016 à 20:05:06, Chri

Re: [swift-evolution] Ad hoc enums / options

I don't understand this. All of what you said applies to structs and does not apply to tuples. What makes it fundamentally impossible to have a "tuple-like enum"? Félix > Le 1 juin 2016 à 20:56:27, L. Mihalkovic via swift-evolution > a écrit : > > > > On Jun 1, 2016, at 11:38 PM, Tony Alle

Re: [swift-evolution] Ad hoc enums / options

I was once relying on the state of things to judge the validity of some access modifier claims and I was rebuked on the grounds that proposals should be evaluated based on their merits, not on implementation details. And as far as implementation details go, this doesn't match what I understand

Re: [swift-evolution] Ad hoc enums / options

You talked about the "compiler's point of view" and said about tuples that "the compiler never thinks that they are the same type". At which level is that true if we're not talking about the internal workings of the compiler? There is consensus that Swift does not currently allow enums to be def

Re: [swift-evolution] Ad hoc enums / options

If there's any interest in going down that road, it seems to me that the only viable option is to allow subsets to be convertible to their superset. Items of (.foo | .bar) would be convertible to (.foo | .bar | .baz), but not the opposite (and not necessarily, although preferably, through a simp

Re: [swift-evolution] Add conversion String -> Bool

I'm not particularly in favor of a String initializer for booleans. In fact, I'm not particularly in favor of a String initializer for any numeric type. Swift's String design ensures that developers can't make assumptions about encodings and a more international alphabet, which is a net win for

[swift-evolution] Arbitrary-sized integers

I'm writing a program that would need Int128s. Since Swift uses LLVM and LLVM has good support for arbitrary-sized integers (well, up to 2^24 bits anyways), I was wondering if there was any interest in having arbitrary-sized integers in Swift. Félix

Re: [swift-evolution] Arbitrary-sized integers

weeks ago: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018957.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018957.html> > >> On Jun 15, 2016, at 5:50 AM, Félix Cloutier via swift-evolution >> mailto:sw

[swift-evolution] Fixing modules that contain a type with the same name

Hello all, I recently ran into a bug that leaves me unable to fully-qualify the name of a type. If you import a module named Foo that also contains a type named Foo, attempts to fully-qualify any name in the Foo module will instead attempt to find so

Re: [swift-evolution] Why hard-code octet-sized bytes?

Out of curiosity, can you name an architecture that doesn't use 8-bit bytes? Félix > Le 17 juin 2016 à 13:01:33, Daryle Walker via swift-evolution > a écrit : > > When I first looked into Swift, I noticed that the base type was called > “UInt8” (and “Int8”) and not something like “Byte.” I k

Re: [swift-evolution] Fixing modules that contain a type with the same name

If no one has anything to say, I'll be starting a proposal to introduce the _.Module.Type syntax. Félix > Le 17 juin 2016 à 19:52:45, Félix Cloutier via swift-evolution > a écrit : > > Hello all, > > I recently ran into a bug <http://stackoverflow.com/q/37892621

Re: [swift-evolution] Fixing modules that contain a type with the same name

gt;> to disambiguate extension methods, with the thought being we could then use >> the same syntax to differentiate top-level names as well. >> >> I'd also be happy with the "import as" syntax. The underscore syntax seems a >> little opaque, but

Re: [swift-evolution] Fixing modules that contain a type with the same name

aging Paulo Faria to mention this case in his push for a >>> way to disambiguate extension methods, with the thought being we could then >>> use the same syntax to differentiate top-level names as well. >>> >>> I'd also be happy with the "import as" synt

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

Do we lose the ability to create a signed integer from an unsigned bit pattern? Is there a way to get an optional initializer that returns `nil` if the operand can't be represented? What is the cost of heterogeneous comparison? Félix > Le 22 juin 2016 à 22:42:00, David Waite via swift-evolutio

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

Thanks for answering my questions earlier. I like a lot of the changes. Speaking of heterogeneous comparisons again, though, how are comparisons of negative signed integers with unsigned integers handled? Félix > Le 23 juin 2016 à 17:36:14, Max Moiseev via swift-evolution > a écrit : > >> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

I'd like to point out that while NoReturn does indicate that the function can't return, this works because a function that can't return may well declare any return type that it likes, not necessarily just NoReturn. It's confusing to see `@noreturn func foo() -> Int`, but it's not much better to

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

Okay, well, I'm +1 on this. I like that we got rid of conversions from/to U/IntMax in favor of more general initializers and the bitshift enhancements. I think that most generic algorithms on integers will get simpler. I'm not overly concerned/competent with floating-point numbers, but I'm sure

Re: [swift-evolution] Fixed-sized arrays

There have been proposals about that, revolving around creating a new tuple syntax for fixed-size arrays, like (Int x 5), and adding a subscript to them. IIRC, the sentiment was largely positive but people couldn't agree on the specific syntax. I pushed a little bit for CollectionType on these,

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

I don't have anything against it, besides that it is an additive feature and should probably wait for after Swift 3. Félix > Le 27 juin 2016 à 07:22:42, David Rönnqvist via swift-evolution > a écrit : > > +1. This makes sense to me. > > Since the API Guidelines say: “Prefer methods and prop

Re: [swift-evolution] [Idea] Syntactic sugar for using methods as functions

Wow. I did not see that coming! Either way, I agree that Foo.bar works, but then again, so does Enum.value and we give that one a free pass. Beyond "it's not how it works right now", I don't really have any serious argument against the feature. I'd like to have that at some point. Félix > Le

Re: [swift-evolution] Proposal SE-0009 Reconsideration

That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler. There is an open bug on SwiftLint

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

My understanding is that we're trying to avoid directly declaring operator overloads as this pollutes the global namespace and makes operator function lookup slower compared to finding a named function in a named type. Félix > Le 2 juil. 2016 à 05:02:20, Nevin Brackett-Rozinsky via swift-evolut

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0111: Remove type system significance of function argument labels

I personally find that { foo(a: $0, c: $1) } is an already simple enough way to solve that problem. Félix > Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution > a écrit : > > l'd like the way of Python to handle the function signature.Assign lost other > possibility of that functio

Re: [swift-evolution] adding Obj-C syntax to Swift?

I'm personally not in favor of any change for which the main argument seems to be "I like it better this way". Félix > Le 11 juil. 2016 à 20:00:14, Ford Prefect via swift-evolution > a écrit : > > Perhaps one of the most disliked aspects of Swift > is the Rust-like syntax, which requires that

Re: [swift-evolution] executing a string

I've never heard of an app being exploited through selector abuse. Do you have any example of that? Félix > Le 14 juil. 2016 à 08:48:53, Ford Prefect via swift-evolution > a écrit : > > One of the major security flaws of Obj C is > the ability to convert a string into a selector, which > perm

Re: [swift-evolution] Fixing modules that contain a type with the same name

a way >> to disambiguate extension methods, with the thought being we could then use >> the same syntax to differentiate top-level names as well. >> >> I'd also be happy with the "import as" syntax. The underscore syntax seems a >> little opaque, bu

Re: [swift-evolution] Fixing modules that contain a type with the same name

odule) are breaking changes. Félix > Le 16 juil. 2016 à 16:01:28, David Hart a écrit : > > I don't see anything source breaking here. I'm fairly sure it's 100% additive > and will therefore wait for after Swift 3. > > On 17 Jul 2016, at 00:19, Félix Cloutier vi

Re: [swift-evolution] Fixing modules that contain a type with the same name

wift.evolution/1394 > <http://permalink.gmane.org/gmane.comp.lang.swift.evolution/1394> and I have > a draft of a proposal that I hope to put out soon that I can let you view (or > even coauthor if you desire) if anybody wishes to ping me off-list. > > ~Robert Widmann > &

  1   2   3   >