Re: [swift-evolution] [Proposal]: support disable to trailing closure syntax

I like this syntax, but I don't like that it could be ambiguous with successively calling animateWithDuration then some function called completion. Other than that, I think that developers should be smart enough to exercise self-restraint with trailing closures when they're not appropriate. I

Re: [swift-evolution] Declaring a function that always returns nil

IMO, this is the best way to approach it. Félix > Le 3 janv. 2016 à 22:54:17, Jack Lawrence via swift-evolution > a écrit : > > You could also use type inference on the return type: > > 1> func returnsNil(errCode: Int) -> T? { > 2. print(errCode) > 3.

Re: [swift-evolution] Trial balloon: Ensure that String always contains valid Unicode

There are precedents for lazily checking for validity after bridging. Using `array as! [T]` on a NSArray without generics fails lazily if you access an object that's not a T. Félix > Le 4 janv. 2016 à 14:59:47, Dmitri Gribenko via swift-evolution > a écrit : > >

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

For the folks who don't mix Swift and Objective-C that much, extensions on @objc classes are exposed to the Objective-C runtime, so there is a discrepancy here. I'm not passionate about the outcome, just dropping the info. Félix > Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

How would this extend to third-party libraries that evolve independently of Apple's release schedule and to the Linux compiler? Is a patch scoped to the executable object that declares it? For instance, if I have a patch in a library, do applications that link against it see the patch? If I

Re: [swift-evolution] Philosophy question: Foundation and Standard Library

My understanding is that Foundation closely maps to the ObjC Foundation framework. Félix > Le 31 déc. 2015 à 17:54:39, Erica Sadun via swift-evolution > a écrit : > > Under what criteria should we propose moving items into the standard library > and out from the

Re: [swift-evolution] Proposal: Add SequenceType.first

No one appears to have considered the C# example yet. In C#, IEnumerable (Swift's SequenceType) has a `First()` (and `FirstOrDefault(T)`) method. C# also has a coroutine syntax (`yield return xyz`) that makes it easy to create sequences that are evaluated with side effects. However, Googling

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

This sounds interesting. I don't have time to read it right now but I like the idea and I'll give better feedback later. Félix > Le 2 janv. 2016 à 12:28:10, Kostiantyn Koval via swift-evolution > a écrit : > > Hi, Happy 2016. > > The proposal looks great as for

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Extensions on classes already work and I can't see them requiring @objc or @nonobjc. It's extensions on protocols that don't work from Objective-C. The way I understand it, Doug suggests a warning/error for extensions on @objc protocols, and a @nonobjc attribute to shut it up. Your point may

Re: [swift-evolution] Default lazy constructor

Have you heard of the property behaviors proposal? Félix > Le 5 janv. 2016 à 08:48:03, James Campbell via swift-evolution > a écrit : > > When creating a lazy variable, maybe we should allow for default closures, i.e > > lazy var userSession: UserSession > > Which

Re: [swift-evolution] Type Safe Algorithms

There are lots of people who had an idea like this one, the latest just yesterday, where the other threads had been collected: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005353.html

Re: [swift-evolution] Explicity Size Clipping

I don't understand. Can you show a code example? Félix > Le 6 janv. 2016 à 13:02:43, James Campbell via swift-evolution > a écrit : > > I have a overloaded method for a protocol that takes an Int or double. > > I have an issue with swift calling the Int version

Re: [swift-evolution] Explicity Size Clipping

I either don't understand or can't reproduce the issue. This code: > class Box { > let value: Int > > init(value: Int) { > self.value = value > } > } > > let test: UInt32 = 4 > let box = Box(value: test) does not compile ("foo.swift:10:22: error: cannot

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

Do you use them a lot outside of a Cocoa/UIKit context? Félix > Le 6 janv. 2016 à 00:08:35, John Randolph via swift-evolution > a écrit : > > Sorry if this is a repeat, but I’d like to suggest promoting certain structs > from Foundation to the Swift standard

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I stand corrected. Félix > Le 5 janv. 2016 à 22:19:28, Charles Srstka a écrit > : > >> On Jan 5, 2016, at 9:06 PM, Félix Cloutier > > wrote: >> >> The linker is smart enough to get rid of frameworks that you don't

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

The linker is smart enough to get rid of frameworks that you don't actually use. Félix > Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution > a écrit : > >> On Jan 5, 2016, at 8:29 PM, Greg Parker > > wrote:

Re: [swift-evolution] [Proposal]: Rectangles and other common structures.

NSRect and CGRect are already the same type and can be used interchangeably: > typedef CGRect NSRect; You can easily typealias CGRect to Rect as well if you don't like the two-letter prefix. Otherwise, if you can wait a bit, SE-0005

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

Meta: most reviews have the review dates in the Status field of their document, this one doesn't. I was a little confused at first. For the proposal itself: # What is your evaluation of the proposal? +1 # Is the problem being addressed significant enough to warrant a change to Swift? Yes, I

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Currently, they can be disambiguated using (self as ProtocolA).bar(), no? Félix > Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution > a écrit : > > Talk about things you didn't know you needed until you see them. This is a > really nice way of

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Right. Félix > Le 29 déc. 2015 à 15:04:11, Douglas Gregor a écrit : > > > > Sent from my iPhone > > On Dec 29, 2015, at 11:48 AM, Félix Cloutier > wrote: > >> Currently, they can be disambiguated using (self as

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

As the resident you-can-already-do-this grumpy guy, I tend to agree that most protocols aren't easily amenable to forwarding, and this solution works too. In general, I think that Swift already doesn't impose too much boilerplate, and I think that most features to reduce boilerplate would be

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

NSControl and subclasses have an action property and a target property but no method to set both at once (in opposition to, say, NSTimer, which has methods that accept a target and a selector at the same time). Félix > Le 30 déc. 2015 à 11:52:41, James Campbell a écrit : >

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers. I also remember someone from Apple confirming what Brent said but I can't find it at the moment. Félix > Le 3 janv. 2016 à

Re: [swift-evolution] [Proposal] Protocols on Steroids

Please split this in smaller pieces. Nobody will want to discuss all of it at once. Félix > Le 30 déc. 2015 à 17:50:44, Howard Lovatt via swift-evolution > a écrit : > > Proposal: Protocols on Steroids > === > > Change the way protocols and

Re: [swift-evolution] [Pitch] make @noescape the default

In general, any case where you go from immediate evaluation to lazy/delayed evaluation. That change might not be the most frequent, but in my opinion, public interfaces should be as forward compatible as possible. Assuming that the closure escapes is always safe and the only difference that I

Re: [swift-evolution] Optional dictionary subscripts

if let value = map(key) { dict($0) } Félix > Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution > a écrit : > > if let key = key, value = dict[key] { >...whatever... > } > > seems to work fine without introducing a new construct > > -- E, waving hi to

Re: [swift-evolution] Proposal Sketch: Bring flexible array members in as Array|UnsafeReference

In general, I find that importing C arrays is problematic. I don't have any nice solution to offer, though. For now, you might be able to get away with withUnsafePointer() { ... }. Félix > Le 22 déc. 2015 à 17:29:10, T.J. Usiyan via swift-evolution > a écrit : >

Re: [swift-evolution] ternary operator ?: suggestion

This is essentially the latest proposal that Paul offered. Félix > Le 22 déc. 2015 à 13:11:37, Thorsten Seitz a écrit : > > I still don't understand why we are not simply writing > > let i = switch color { > case .Red: 0xFF > case .Green: 0x00FF00 >

Re: [swift-evolution] ternary operator ?: suggestion

or] > > this would mean that color must be a Color and not an Optional > (because of swift 2.x limitations) > > -DW > >> On Dec 22, 2015, at 8:04 AM, Félix Cloutier via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.or

Re: [swift-evolution] Immutable Structures

The current choice is that if you need pass-by-value semantics, you use a struct; if you need pass-by-reference semantics, you use a class. This is almost only relevant when structs are mutable: the only semantic difference between a struct and a class is that mutating a struct won't have an

Re: [swift-evolution] Immutable Structures

No, this is a consequence of structures being passed by value to property accessors. The getter doesn't return a reference to the frame, it returns a copy of it, so it is accompanied by a hidden set operation where it replaces the whole thing. Félix > Le 23 déc. 2015 à 11:09:43, Kevin

Re: [swift-evolution] [Pitch] Guarding on enum values

I feel exactly like Brent. Félix > Le 23 déc. 2015 à 04:15:24, Brent Royal-Gordon via swift-evolution > a écrit : > >> guard case let .Succeed(m) = returnsResult() else { >>return it >> } >> // Can safely use m, otherwise Result is passed back the call

Re: [swift-evolution] [Proposal] Make `didSet` also available for `let` property, or something new such as `didInit`

willSet and didSet are currently not even called from the init method. This also goes counter to the current property behaviors proposal (didGet and didSet would become part of that) because behaviors aren't planned for let properties. You're saying you want it to happen as soon as it was set,

Re: [swift-evolution] Pitch: Copy constructors for structs

Oh well. I thought I had done due diligence! One less thing to be wrong about in the future. Félix > Le 24 déc. 2015 à 16:07:25, Joe Groff a écrit : > > >> On Dec 24, 2015, at 1:04 PM, Félix Cloutier wrote: >> >> At which point does that happen? The O0

Re: [swift-evolution] Pitch: Copy constructors for structs

At which point does that happen? The O0 SIL for it has an alloc_stack $Point in main. Otherwise, that's hard-to-predict copy elision at work anyway. Félix > Le 24 déc. 2015 à 14:40:13, John McCall <rjmcc...@apple.com> a écrit : > >> On Dec 23, 2015, at 2:18 PM, Félix

Re: [swift-evolution] [Proposal] Make `didSet` also available for `let` property, or something new such as `didInit`

I'm just one person out of many on this list that you can convince. However, it's gonna be an uphill battle to get my vote. I see the small clarity benefit that this brings but I also see big problems that you didn't mention. First, property observers are currently not fired from initializers.

Re: [swift-evolution] Immutable Structures

If you're serious about your proposal, you need to come up with a realistic plan for phasing out the current struct semantics for everyone, in every use case that they have. Félix > Le 26 déc. 2015 à 11:14:44, Lino Rosa via swift-evolution > a écrit : > > > > "1)

Re: [swift-evolution] Adding custom attributes

Consider reading the Property Behaviors proposal, as attributes overlap with it. (Warning: lng thread) Félix > Le 26 déc. 2015 à 13:57:04, JOSE MARIA GOMEZ CAMA via swift-evolution >

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

My understanding is that Swift 3 will stabilize the ABI and the standard library interfaces. Given that, I'm not sure what you'd use it for either. > Le 19 déc. 2015 à 14:26:24, Javier Soto via swift-evolution > a écrit : > > What's the intended most common use case

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

I don't really like how different this makes "#if swift" from "#if ". To me, that would be a violation of the principle of least astonishment. > Le 19 déc. 2015 à 17:08:13, David Farler via swift-evolution > a écrit : > > > >> On Dec 19, 2015, at 13:48, Michel

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

I'm not sure I understand your comment either. If I understand correctly, you say that the problem I describe is applicable only to polymorphic types (which is true). However, you then say that the only option today is polymorphic error types. Isn't that an issue? (Also, why is it the only

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

No, because an enum on top of an enum can only restrict the enumerants, not add new ones. An exception hierarchy increases the number of possibilities; an enum-backed enum decreases the number of possibilities. > Le 18 déc. 2015 à 12:21:47, Dennis Lysenko a > écrit

Re: [swift-evolution] [Review] Constraining AnySequence.init

The URL is right (https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md), but the link points to a different proposal (https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md). Copy-paste it to

Re: [swift-evolution] RFC: Proposed rewrite of Unmanaged

There's still the "release" issue (std::unique_ptr::release versus -[NSObject release]), but "transfer" seems like a good word to me. What about "transferByRetaining" and "transferWithoutRetaining"? Félix > Le 20 déc. 2015 à 00:01:22, Nevin Brackett-Rozinsky via swift-evolution >

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

It's not surprising that what's inside an #if swift block isn't compiled, but since it doesn't, it might be surprising that what is inside an #if DEBUG block is compiled, no? > Le 19 déc. 2015 à 17:58:35, David Farler a écrit : > > I don't know if I would say it violates

Re: [swift-evolution] Proposal: Rewrite Swift compiler in swift to get ideas for further language evolution.

Beyond whether or not a standard library provides a better simulation of "actual programming" than a standard library, making a Swift compiler in Swift is a massive undertaking. The Go maintainers started working on a self-hosting compiler 3 years after the language's initial release and it

Re: [swift-evolution] [Pitch] Guarding on enum values

Wait, no, there's a problem with that. You can't use `r` in the guard scope because `returnsResult()` might not have succeeded. Félix > Le 24 déc. 2015 à 09:37:36, Félix Cloutier via swift-evolution > <swift-evolution@swift.org> a écrit : > > I like that it's consistent

Re: [swift-evolution] [Pitch] Option parameters (potential resilience advantages)

The current workaround is to add an overload that calls the "main" version: > class Foo { > // version 1 > func foo() { > print(5) > } > > // version 2 > func foo() { > foo(5) > } > > func foo(value: Int) { >

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Would it be possible to add properties to closures/method objects? Right now, it's possible to write: > @objc > class Foo : NSObject { > func doSomething(value: Int) -> Int { > return value + 1 > } > } > > let method = Foo.doSomething Maybe we could have

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

I really only was talking about the case where the compiler knows that it's an @objc method (with the understanding that the information is lost as soon as you make an unattributed T -> U closure out of it). Either syntax would make me happy. Félix > Le 28 déc. 2015 à 13:49:22, Joe Groff

Re: [swift-evolution] [Pitch] Use enums as enum underlying types

I agree that there's something about the inheritance that's inside out, since the enum restricts the domain of the underlying type instead of expanding it. However, it is consistent with the current enum semantics when they're based off raw values. It seems to me that the relationships

Re: [swift-evolution] Coroutine for Swift

There's probably some additional work to do on the proposal document, but I would like to see coroutines in Swift too. The feature has been very successful in other languages like Python and C#, and unless I'm mistaken, work is being done to standardize it in C++. Generators are one use case,

Re: [swift-evolution] ternary operator ?: suggestion

In my opinion, the operator has a future. Swift is merely moving away from C-style constructs that promote mutable state. This kind of inline switch expression actually reminds me of pattern matching constructs in functional languages, and it may pick up more steam if the proposal for

Re: [swift-evolution] Proposal: One-past-end array pointers and convertibility of nil for interaction with C APIs

The & operator isn't exactly an address-of operator. Does [0] even return a pointer to the inner buffer? When you use & with properties (and possibly with subscripts as well), Swift may create a local, copy the property value to it, pass a pointer to that local, and copy back the output to the

Re: [swift-evolution] Pitch: Deinit for structs

Just chiming in with you two: deinit for a struct doesn't really work because structs are copied and destroyed all the time. Putting a file descriptor in a struct (along with destruction logic) would fail pretty hard without C++-like copy/move semantics. Félix > Le 23 déc. 2015 à 16:21:42,

Re: [swift-evolution] Epic: Typesafe calculations

My college calculator had that, and once I discovered it I never went back. For sure, if I did anything remotely scientific with Swift, I would be in love with the feature. I'm not very good with functional programming but that sounds like something functional programming folks would have a

Re: [swift-evolution] Proposal: Add .times method to Integer type

The Foundation framework is being ported to other platforms and it has CGSize and NSDate (but not NSImage/UIImage). For the rest, the Swift package manager will probably fulfill that role, no?

Re: [swift-evolution] Using "where" to filter an array

That would be a weak -1 for me too, but only because I don't like the where syntax on control structures. Félix > Le 20 déc. 2015 à 01:31:28, Jacob Bandes-Storch via swift-evolution > a écrit : > > A weak -1. > > I'm not certain that my argument holds up very

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

My understanding is that you suggest using the "do using" statement for two purposes: to deterministically free resources (files, sockets); to create a scope with a guarantee about something (locks). The first purpose is very relevant for garbage-collected languages because the GC generally

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

Re: [swift-evolution] Arbitrary-sized integers

; wrote: > 128-bit Ints have been discussed here a few 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,

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

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,

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,

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

[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

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

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

t;> I've been encouraging 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

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

>> 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 I suppose

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 >

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

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] 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

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] Making pointer nullability explicit (using Optional)

> Fortunately, when a type has a single invalid value for which no operations > are valid, Swift already has a solution: Optionals. To me, this makes it sound like dereferencing an unsafe pointer is unsafe only if the pointer is nil. (Nil does have the merit that it's generally one of the only

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

GCC may have some hints: > -fdelete-null-pointer-checks > Assume that programs cannot safely dereference null pointers, and that no > code or data element resides at address zero. This option enables simple > constant folding optimizations at all optimization levels. In addition, other >

Re: [swift-evolution] Base types casting and hidden function calls in SWIFT

How did you come to that conclusion? In Swift 2.1 (I'm late to update), with optimizations on, this function: > func test() -> Double { > return Double(arc4random()) > } compiles to: > define hidden double @_TF4test4testFT_Sd() #0 { > entry: > %0 = tail call i32 @arc4random() > %1 =

Re: [swift-evolution] Making pointer nullability explicit (using Optional)

17, 2016, at 8:21 PM, Félix Cloutier via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> Fortunately, when a type has a single invalid value for which no operations >>> are valid, Swift already has a solution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0047 Defaulting non-Void functions so they warn on unused results

Sorry for how informal this review is; I'm generally in favor of it, although I would recommend that imported C functions are by default tagged with @discardableResult. Félix > Le 17 mars 2016 à 07:33:10, Tino Heth via swift-evolution > a écrit : > >> Perhaps we

Re: [swift-evolution] [Proposal] Custom operators

That doesn't sound future-proof. If it was in place and Range hadn't existed since the earliest Swift public release, it wouldn't be possible to define its precedence now. Félix > Le 3 avr. 2016 à 11:41:00, Ben Rimmington via swift-evolution > a écrit : > >

Re: [swift-evolution] Base types casting and hidden function calls in SWIFT

How did you come to that conclusion? In Swift 2.1 (I'm late to update), with optimizations on, this function: > func test() -> Double { > return Double(arc4random()) > } compiles to this IR: > define hidden double @_TF4test4testFT_Sd() #0 { > entry: > %0 = tail call i32 @arc4random() >

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] [Proposal] Move public AutoreleasingUnsafeMutablePointer API from StdlibCore -> Objective C Overlay

I agree on principle for moving it out of stdlib, but what's the Objective-C overlay? Félix > Le 21 juil. 2016 à 10:02:46, Michael Gottesman via swift-evolution > a écrit : > > Hello everyone. > > This is a proposal to move AutoreleasingUnsafeMutablePointer from

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

I'm +1 on the proposal. Félix > Le 27 juil. 2016 à 07:08:44, Xiaodi Wu via swift-evolution > a écrit : > > Ben, while I'm broadly sympathetic to making CChar work more widely, if I > recall correctly this was a rather complex discussion topic you're raising >

Re: [swift-evolution] [Draft] Fix a typo in two String methods

So I can see in hindsight that perhaps people meant "NUL-terminated string" the whole time, but "NUL-terminated string" has 19,700 results on Google, whereas "null-terminated string" has 192,000. I have a funny anecdote to share. I got really upset on reddit one day

Re: [swift-evolution] Type access level as the default for its members?

The only point that judges the proposal on its merits would be the first one, and I would personally be happy to have that discussion. Félix > Le 22 juil. 2016 à 10:14:13, Jose Cheyo Jimenez via swift-evolution > a écrit : > > > > On Jul 22, 2016, at 3:34 AM,

[swift-evolution] [Meta] What does the backlog mean to the process?

Hello all, With the Swift 3 deadline passed, according to the Swift Evolution progress page, about 20% of the proposals that the community voted in won't make it for Swift 3. Beyond the implications for the language itself, what does that mean for the swift-evolution process? Félix

Re: [swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

Seems to me that we can find similar information just from walking over a class's fields to build an ownership graph, and cause warnings/errors when you find a strong cycle. How do you deal with type erasure? > protocol Foo {} > class A { > var foo: Foo > } > class B: Foo { > var

Re: [swift-evolution] [Discussion] Breaking precedence

I don't think that "intuitive" or "non-intuitive" is what you'd be looking for. There is nothing intuitive about multiplications having a higher precedence than additions; it's just a matter of conventions. I'm not a maths expert (as Stephen showed, I didn't even give the right explanation to

Re: [swift-evolution] [Discussion] Breaking precedence

These expressions mix two types of logic that have different implications. For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 16` will crash on overflow. In these cases, I find that grouping provides some visual insulation that groups off the somewhat subtle

Re: [swift-evolution] [Discussion] Breaking precedence

I disagree. The binary operators have properties that are comparable to arithmetic operators, and their precedence is easy to define as such. & has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like

Re: [swift-evolution] ABI of throwing

: Y_1 * (1/P) + N_1 < Y_2 * (1/P) + N_2 in which Y completely dominates N, especially as P goes smaller. Félix > Le 9 août 2016 à 16:22:08, John McCall <rjmcc...@apple.com> a écrit : > >> >> On Aug 9, 2016, at 8:19 AM, Félix Cloutier via swift-evolution &g

Re: [swift-evolution] Proposal for swift build linux on Mac os x

The swift-evolution mailing list is about the language itself, Xcode is independent. I don't know where you could try to push that suggestion. Félix > Le 13 août 2016 à 16:40:42, apps4u via swift-evolution > a écrit : > > I have a Proposal but I'm not sure if Its

Re: [swift-evolution] [Proposal] Sealed classes by default

There was an order of magnitude more than 60 emails about this. In my inbox, I count 452 emails that have 0117 in the title. Discussion had already started before the proposal and I'm not counting these. Félix > Le 14 août 2016 à 02:17:36, John Holdsworth via swift-evolution >

Re: [swift-evolution] Why have both bit-wise and logical operators?

Also, bitwise operators have precedence over comparison operators. `if foo == bar && baz == frob` would have to be replaced with `if (foo == bar) & (baz == frob)`. Félix > Le 12 août 2016 à 14:59:27, John McCall via swift-evolution > a écrit : > >> On Aug 12,

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

Can we do a quick recap? Please correct me if I'm wrong. UnsafePointer: pointer to memory that the compiler may assume to be typed. Bounds unknown. UnsafeBufferPointer: pointer to several objects that the compiler may assume to be typed Bounds known. UnsafeRawPointer: pointer to memory that the

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

And then, we can't really use UnsafeBufferPointer for the purpose of UnsafeBytes because we want to expose a different API. Is that right? Félix > Le 13 août 2016 à 01:44:28, Andrew Trick a écrit : > > >> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

My understanding is that we want "using" and "hiding" because we want the ability to either take just a few things OR leave out just a few things. With a unified "import Foo (A = B, C = D, E = _) syntax, we only get the ability to take a few things AND hide a few things. I've never really been

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

from Foo" than "don't take Baz from Bar". Félix > Le 20 juil. 2016 à 20:46:18, Robert Widmann <devteam.cod...@gmail.com> a > écrit : > > > > ~Robert Widmann > > 2016/07/20 20:07、Félix Cloutier via swift-evolution > <swift-evolution@swift.org

  1   2   3   >