Re: [swift-evolution] Epic: Typesafe calculations

Same here. I can fake a bit of it now by creating the relevant types ("struct _1 {...}", etc), but it's *very* fragile. > On Dec 31, 2015, at 14:18, Matt Whiteside via swift-evolution > wrote: > > >>> On Dec 31, 2015, at 09:25, Dave Abrahams via swift-evolution

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 2, 2016, at 12:57 PM, John McCall wrote: > >> On Jun 2, 2016, at 10:49 AM, David Sweeris > > wrote: >> I’m not entirely sure what an “expr-collection” is. > > Collection literals, e.g. [x,y,z] and [a: x, b: y].

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

ser-defined ‘lossless’ string. > > Patrick > >> On 5 Jun 2016, at 1:25 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Jun 4, 2016, at 15:46, Jacob Bandes-Storch via swift-evolution >>> <swift

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

You forgot one :-) let capitalizedA = ModuleA { "hello swift".capitalized() } +1 on finding a way to explicitly resolve naming collisions. I'm generally in favor of something like #2 (or #3). A while back, there was a proposal to replace numerical operator precedence with a relative

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

> On Jun 4, 2016, at 15:46, Jacob Bandes-Storch via swift-evolution > wrote: > > - The "lossless" protocol will be a welcome addition for > serialization/deserialization code, and it makes the replacement init(_:) API > very clear in its behavior. Speaking of

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

+1 Sent from my iPhone > On Jun 12, 2016, at 08:01, Антон Жилин via swift-evolution > wrote: > > I've prepared a proper draft: > > https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md > > - Anton > > 2016-06-10

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution > wrote: > This might be silly, but what if there were a struct with all of the relevant > fields (not sure what the best name would be): > > struct MemoryLayout { > let

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

In defense of MemoryLayout's "less clarity", the people who know enough to use that stuff won't have trouble understanding it. That said, while I like it, I'm mostly interested in sequestering this stuff away in a type as a step towards a some sort of vague macro system. Since that's obviously

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

> On Jun 3, 2016, at 16:17, Matthew Johnson via swift-evolution > wrote: > > Using an external parameter label in a declaration and allowing it to be > omitted at the call site does not feel like the right answer to me. I think > we can find a better way to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 24, 2016, at 8:06 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 24, 2016, at 7:45 PM, Brent Royal-Gordon > > wrote: >> >>> I believe it was things like "+" and "-" for set union and

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution > wrote: > >> >> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon > > wrote: >> >>> Upon accepting SE-0099, the core team is removing `where`

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

You may be right, but I'd imagine such a conversion function would be in pretty much any library for serializing/deserializing data. I can't recall if this has been discussed before, but are we committed to One Standard Library to Rule Them All, or might we consider having a "standard" library

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

If you're asking me, it depends on what gets filled in for "syntax". I see no reason to explicitly prohibit classes from participating, though. - Dave Sweeris > On May 30, 2016, at 16:12, Vladimir.S wrote: > > In case we discuss this feature not for just value types but for

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I'd interpret that as being able to write: var x: Int8 { 20 } as opposed to: var x: Int8 { Int8(20) } - Dave Sweeris > On May 31, 2016, at 12:47, David Rönnqvist via swift-evolution > wrote: > > Under "Proposed solution" you say (emphasis mine): > > "Make return

Re: [swift-evolution] Variadic generics discussion

Out of curiosity, why? - Dave Sweeris > On May 31, 2016, at 12:59 PM, Austin Zheng via swift-evolution > wrote: > > How so? I'm interested in anything that can get us away from having to > generating code at compile-time. > > On Tue, May 31, 2016 at 10:04 AM, L.

Re: [swift-evolution] [Proposal] Enums with static stored properties foreach case

> On May 25, 2016, at 10:27 PM, Jacob Bandes-Storch <jtban...@gmail.com> wrote: > > On Wed, May 25, 2016 at 8:15 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > On May 25, 2016, at 7:37 AM, Le

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

On May 25, 2016, at 6:17 PM, David Hart via swift-evolution wrote: > > Hello, > > This is a new pitch to allow explicitly specializing generic functions. > Notice that potential ambiguity with initialisers and how I’m currently > trying to avoid it. Please let me

Re: [swift-evolution] [Proposal] Enums with static stored properties foreach case

On May 25, 2016, at 7:37 AM, Leonardo Pessoa via swift-evolution wrote: > > Hi, > > Couldn't this be solved by using tuples? If not because the syntax is not > allowed I think this would be more coherent to do it using current syntax. > > enum Planet : (mass:

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

I’m not entirely sure what an “expr-collection” is. Does your proposal mean that in this code: func foo() -> Int {...} var w = 0 var x = T(foo()) var y = T(w) var z = T(0) different initializers would be used for `x`,`y`, and `z`? If so, that seems a potential source of much subtler problems. I

Re: [swift-evolution] [Pitch] Remove associated type inference

I’m inclined to say -1, for reasons that’ve already been mentioned, but can anyone elaborate on “a drastically different architecture to the type checker”? - Dave Sweeris > On May 25, 2016, at 4:43 PM, David Hart via swift-evolution > wrote: > > Here’s a pitch for

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

+1 for "deriving", "synthesizes", or some other keyword. How are we going to tell the compiler what protocols can participate? Something like "@memberwise" is all I can think of, but I'm too tired for deep thought at the moment. - Dave Sweeris > On May 26, 2016, at 21:57, Ricardo Parada via

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

What about declaring the requirements for auto-conformance in a sub-protocol? @auto protocol AutoEquatable : Equatable { //"syntax" for how to conform to Equatable } struct Foo : AutoEquatable {} //the compiler automatically synthesizes everything struct Bar : Equatable {} //you manually

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

> On Jun 21, 2016, at 17:26, Xiaodi Wu via swift-evolution > wrote: > > The \( combination takes a little getting used to, but it's not absurdly > terrible. I suppose we could consider \{} or even \[] instead of \() to > alleviate the reach. \{} is kinda nice

Re: [swift-evolution] Arbitrary-sized integers

> On Jun 15, 2016, at 10:58 AM, Félix Cloutier via swift-evolution > wrote: > > I know that one, but I merely need fixed-size big integers. Backing all of my > integers with an array seems overly expensive. > > Félix > >> Le 14 juin 2016 à 23:25:16, T.J. Usiyan

Re: [swift-evolution] Normalizing operator's types

Function currying wasn’t removed, just some of the confusing syntax for it. This works fine in the Xcode 8 beta: infix operator <> {} // random operator that doesn’t do anything else func <> (op: (T, U) -> V, rhs: U) -> ((T) -> V) { return { op($0, rhs) } } func <> (lhs: T,

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

IIRC, a bunch of Ye Olde systems used 6-bit bytes. And I think 36-bit ints were used in a few architectures, but don't quote me on that. - Dave Sweeris > On Jun 17, 2016, at 22:48, Félix Cloutier via swift-evolution > wrote: > > Out of curiosity, can you name an

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 22, 2016, at 19:35, Dmitri Gribenko wrote: > >> On Wed, Jun 22, 2016 at 5:15 PM, David Sweeris wrote: >> That's a really interesting idea. Is "Syntax" a placeholder, or is that the >> intended name? > > It is the best name we could come up

Re: [swift-evolution] Revisiting SE-0041 Names

That's a really interesting idea. Is "Syntax" a placeholder, or is that the intended name? Also, why an enum? Especially one without any cases... Was all this already discussed in a thread that I missed (or have otherwise forgotten about)? - Dave Sweeris Sent from my iPhone > On Jun 22,

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

-1 for all the reasons already mentioned. Although, if we end up accepting this anyway, FWIW I'd prefer "DoesNotReturn" or "NeverReturns" over "NoReturn" or "Never". They both read better to me, and their imperative names help make it clearer that something is different. - Dave Sweeris > On

Re: [swift-evolution] Shorthand unwrap proposal

Dmitri pointed out a few posts ago that Swift already has this. let opInt: Int? = nil opInt.map {$0.toIntMax()} //Evaluates to nil Are you talking about something different? - Dave Sweeris > On Jun 23, 2016, at 2:04 PM, Charlie Monroe via swift-evolution > wrote: >

Re: [swift-evolution] Prohibit invisible characters in identifier names

+1 I didn't even know there were any invisible characters until this thread came up. - Dave Sweeris > On Jun 23, 2016, at 15:13, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jun 23, 2016 at 2:54 PM, João Pinheiro wrote: >> >> > On 23

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Sent from my iPhone > On Jun 25, 2016, at 05:06, Karl via swift-evolution > wrote: > > Proposal: https://gist.github.com/karwa/273db66cd8a5fe2c388ccc7de9c4cf31 +1 The only thing I'm worried about is the situation where we have "x = N.M", and `x.ceiling` equals

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

I'm starting to come down from me earlier +1... Floor and ceiling are more functions than properties of a number, aren't they? - Dave Sweeris > On Jun 25, 2016, at 11:48, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > +1 > > The only

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

As someone who’ll likely make use of this protocol, I’m in favor of a “halfWidthDivide” (or whatever it’s called). As someone who’ll likely end up writing at least one type which will conform to `Integer`, I’m not looking forward to implementing 503 little functions & computed properties

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 24, 2016, at 08:27, Vladimir.S via swift-evolution > wrote: > > (Personally I really don't understand why we need anything than ASCII codes > for identifiers. This could solve all the problems with invisible > space/left-to-right-flags/complicated

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 24, 2016, at 23:13, Charlie Monroe via swift-evolution > wrote: > > BTW how far along with programming do you think you'd get without the > knowledge of English? All libraries, SDKs use English identifiers. The > documentation is in English. For one to

Re: [swift-evolution] Revisiting SE-0041 Names

> On Jun 27, 2016, at 13:13, Dave Abrahams via swift-evolution > wrote: > > There's an exception to everything. In this case, protocols used to > interface with the language at the lowest levels may be purely about > syntax. Should we use a different word to

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

That’s a very good point, IMHO. - Dave Sweeris > On Jun 27, 2016, at 2:43 PM, Stephen Canon via swift-evolution > wrote: > > >> On Jun 27, 2016, at 3:34 PM, Saagar Jha wrote: >> >> Seems fine to me. One addition though: some sort of

[swift-evolution] What about failable literal convertibles?

What about having a protocol for having failable literal convertible initializers for literal optionals? struct AtLeast3 : FailableArrayLiteralConvertible { ... init?(arrayLiteral elements: T...) { guard elements.count >= 3 else { return nil } ... } } var bar:

Re: [swift-evolution] Deprecating Trailing Closures

Agreed. Sent from my iPhone On Mar 25, 2016, at 07:44, Brent Royal-Gordon via swift-evolution wrote: >>>let foo = myArray >>>.filter { $0 & 1 == 1 } >>>.map { $0 + 1 } >>>.reduce(0) { $0 + $1 } >> >> This doesn’t really seem much neater

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

> On Apr 2, 2016, at 20:49, Charles Srstka via swift-evolution > wrote: > > While this style works, and definitely can substitute for a classical for > loop, it is not quite as nice, because it cannot limit i’s scope to the loop. > The variable will be visible

Re: [swift-evolution] Allowing Characters for use as Custom Operators

• is the dot product operator. Sent from my iPhone > On Mar 28, 2016, at 10:21, Thorsten Seitz via swift-evolution > wrote: > >> Am 08.01.2016 um 09:38 schrieb Jacob Bandes-Storch via swift-evolution >> : >> >> I'd be hesitant to support

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 9:56 AM, Stephen Canon via swift-evolution > wrote: > > >> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu > > wrote: >> >> Naive question: is it necessary to make a trade-off here? Why not an >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

I’m with Nicola on this one. Operators are currently odd in that they have to be declared globally. Everything else about protocol conformance is kept within the conforming type. - Dave Sweeris > On Apr 26, 2016, at 9:28 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] Overriding computed properties with let constants?

I’m not sure if I like it, but declaring it as a let could disallow subclasses from overriding it, just like any other let. - Dave Sweeris > On Apr 23, 2016, at 2:30 PM, Adrian Zubarev via swift-evolution > wrote: > > I already see the problem here: > > class A {

Re: [swift-evolution] Overriding computed properties with let constants?

Oh, yeah, good point about "final". Would there be a performance difference between "override var x: Int {return 7}" and "override let x = 7"? Sent from my iPhone > On Apr 23, 2016, at 16:06, Haravikk via swift-evolution > wrote: > > I don’t think using a let

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution > wrote: > > I think this specific proposal asking for compiler magic to auto-unwrap > invisibly and only in very limited cases, as this proposal suggests, ends up > breaking a lot more than it fixes. I

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 30, 2016, at 5:42 PM, Rod Brown wrote: > > Re-sent for Swift Evolution. Response at end. > > On 1 May 2016, at 6:31 AM, David Sweeris > wrote: >>> On Apr 30, 2016, at 7:18 AM, Rod Brown via swift-evolution

Re: [swift-evolution] Auto Unwrapping Of Optionals

> On Apr 29, 2016, at 1:23 PM, Haravikk via swift-evolution > wrote: > > This is definitely something I’m hoping to see as well, alongside more > intelligent handling of the is keyword, as currently Swift doesn’t handle the > following either: > > if foo is

Re: [swift-evolution] Extending init checks for property initialization

> On Apr 29, 2016, at 3:00 AM, Vladimir.S wrote: > > Can't see any significant extra overhead because of implicity unwrapped > property for your code. Could you clarify? It's probably not significant in UI code, but if you’re writing something that’ll be accessed a 100k or

Re: [swift-evolution] Extending init checks for property initialization

Eh, “going away” might be too strong… They’re changing a lot. There’s still the extra overhead though. > On Apr 28, 2016, at 7:49 PM, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolut

Re: [swift-evolution] Extending init checks for property initialization

> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution > wrote: > > I think I like this idea. It is clear that it is init() and 'defer' says that > it is called at the end of each init. IMO we need exactly some kind of 'init' > as only in init we can set

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Is that bad? We already have conditional inheritance in classes: class Foo : Bar {} If you move the where clause to the right: class Foo : Bar {} And drop the generic arguments: class Foo : Bar where _constraint_ {} The only difference is “protocol” vs “class”. - Dave

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> On May 23, 2016, at 9:55 PM, Xiaodi Wu wrote: > > On Mon, May 23, 2016 at 9:40 PM, David Sweeris > wrote: > > Have we (meaning the list in general, not you & me in particular) had this > conversation before? This feels

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Can we make it RawRepresentable? That way signum can just return self.rawValue Sent from my iPhone > On May 23, 2016, at 06:05, Charlie Monroe via swift-evolution > wrote: > > The clean way would be to make it an enum with var signum that would return > -1, 0, 1: >

Re: [swift-evolution] [Review] SE-0091: Improving operator requirements in protocols

> On May 18, 2016, at 18:07, plx via swift-evolution > wrote: > > How hard would it be to e.g. simply allow something like this: > > func ==(lhs: T, rhs: T) -> Bool { >return lhs T.== rhs > } > > …instead of the `T.==(lhs,rhs)` syntax? Yeah, I've been

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

I'd prefer they mirror the integer type naming "conventions", that is have an explicit "Float32" and "Float64" type, with "Float" being a typealias for Float64. Sent from my iPhone > On May 23, 2016, at 18:26, Adriano Ferreira via swift-evolution > wrote: > > Hi

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On May 23, 2016, at 8:18 PM, Xiaodi Wu wrote: > > Int is the same size as Int64 on a 64-bit machine but the same size as Int32 > on a 32-bit machine. By contrast, modern 32-bit architectures have FPUs that > handle 64-bit and even 80-bit floating point types. Therefore, it

Re: [swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

Or if there was a way to declare that a class/protocol can only have a defined set of subclasses/conforming types. Sent from my iPhone > On May 24, 2016, at 15:35, Austin Zheng via swift-evolution > wrote: > > If you pattern match on a type that is declared

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

We could make Optional conform to CustomStringConvertible: var description: String { switch self { case .some(let x): return "\(x)" case .none: return "\(Wrapped.self)?.none" } } - Dave Sweeris > On May 18, 2016, at 15:56, Michael Peternell via swift-evolution >

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

Sorry, I misspoke. I just meant define it like this: public enum IntegerSign : Int { case Negative = -1 case Zero = 0 case Positive = 1 public var signum: T { return T(self.rawValue.toIntMax()) } } Although, come to think of it, I’m not sure if that’s an exact drop-in

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

The RawValue is an Int, but signum is a T, which I thought was the point. I tried saying `T: IntegerLiteralConvertible`, and making RawValue = T, but the playground didn’t like that. Maybe with some of Swift 3’s generic enhancements, it could be that simple. In any case, it sounds like this

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

As am I. I like that the while clause can be optional, but I don't see the point of banning "while true". - Dave Sweeris > On May 10, 2016, at 14:10, Xiaodi Wu via swift-evolution > wrote: > > Nicholas wrote that he would like `while true` to be a compile-time

Re: [swift-evolution] Referencing zero-parameter functions

What about :? You could reference "foo()" as "foo:()", "foo(arg: T)" as "foo:(arg:)", and the property "foo" as "foo:". - Dave Sweeris > On May 12, 2016, at 16:40, Alex Hoppen via swift-evolution > wrote: > > Since there doesn’t seem to be much support for the

Re: [swift-evolution] Winding down the Swift 3 release

> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution > wrote: > > That said, it is also clear at this point that some of the loftier goals that > we started out with aren’t going to fit into the release - including some of > the most important generics

Re: [swift-evolution] [Pitch] Parse expressions after 'as' and 'is' instead of just types

+1 - Dave Sweeris > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution > wrote: > > Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd > expect, but does lead to problems when an 'as' expression appears as part of > a comparison:

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

`lazy` properties can't be `let`. Personally, I disagree with this — their initial mutation is transparent, and it's conceptually perfectly valid to have a value that's, say, too expensive to calculate during every instance's init and whose value never changes once calculated — but there may

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 5, 2016, at 5:01 PM, Dave Abrahams wrote: > > > on Wed May 04 2016, David Sweeris wrote: > >>> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution >>> wrote: >>> >>> In order for something like AnyValue to have meaning, we

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 5, 2016, at 10:59 AM, Dave Abrahams wrote: > > > on Wed May 04 2016, Matthew Johnson wrote: > >>> On May 4, 2016, at 4:16 PM, David Sweeris wrote: >>> >>> Having given it some more thought... Does "PureReference" make >>> sense? What would

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 6, 2016, at 19:48, Dave Abrahams via swift-evolution > wrote: > > Sorry, this is the first mention I can find in the whole thread, honest. > Oh, it was a different thread. Joe describes it as a protocol for > “types that represent fully self-contained

[swift-evolution] Should we rename "class" when referring to protocol conformance?

I was just thinking that: protocol Foo : reference {} might be more to the point than: protocol Foo : class {} I know that it’s currently a moot point because classes are the only* reference-semantics type of type in Swift, but it’s conceivable that there might some day be others. Anyway, I’m

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

On May 2, 2016, at 13:10, John McCall <rjmcc...@apple.com <mailto:rjmcc...@apple.com>> wrote: >> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I was just

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

> On May 2, 2016, at 5:58 PM, Chris Lattner via swift-evolution > wrote: > > On May 2, 2016, at 1:56 PM, Dave Abrahams via swift-evolution > wrote: >>> How does one distinguish between calls to a static prefix operator and a >>>

Re: [swift-evolution] [Idea] Make lazy an attribute

Yeah, I was just thinking that we should get the “call-site” syntax settled for property behaviors, for exactly that reason. > On May 2, 2016, at 3:39 PM, Антон Жилин via swift-evolution > wrote: > > One of proposals that will probably be submitted for Swift 4, will

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 13:29, Dave Abrahams via swift-evolution > wrote: > > In order for something like AnyValue to have meaning, we need to impose > greater order. After thinking through many approaches over the years, I > have arrived at the (admittedly rather

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

> On May 5, 2016, at 10:26 AM, Jordan Rose via swift-evolution > wrote: > > (“NeXT” is an especially tricky case because without case it’s not > distinguishable from the normal word “next”. This situation is rare but not > nonexistent. Then again, “Apple” is not

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

So… Is your idea that wrapping a SomeEnum in an Optional would add some “invalid” case to SomeEnum, or that switching on a SomeEnum? would be implicitly rewrite: switch result { case .heads: print("heads") case .tails: print("tails") case .none: print("not yet flipped") // exhaustive } to:

Re: [swift-evolution] Switch on an optional enum -- `case: nil`?

Oh, cool! I didn’t realize this syntax existed. On May 5, 2016, at 10:52 AM, Krzysztof Siejkowski via swift-evolution wrote: > > It doesn’t compile because you’re switching on the Optional and trying to > pattern match it to Coin. > > It compiles right when you

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 5, 2016, at 6:55 PM, Dave Abrahams wrote: > > > on Thu May 05 2016, David Sweeris wrote: > >> I meant leave `struct` and `enum` the way they are, and introduce a >> `different_struct` and `different_enum` (placeholder names, of course) >> which enforced the “no

Re: [swift-evolution] Referencing zero-parameter functions

What’s wrong with `foo()` again? To me, a `_` in the parameter list means that something is there, but the label doesn’t matter. - Dave Sweeris > On May 5, 2016, at 9:42 AM, Alex Hoppen via swift-evolution > wrote: > > The idea of adding a syntax to reference

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 11:12, Joe Groff via swift-evolution > wrote: > > I can see value in there being some kind of PureValue protocol, for types > that represent fully self-contained values, but conforming to that protocol > requires a bit more thought than just

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Johnson <matt...@anandabits.com> wrote: > > >> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On May 4, 2016, at 11:12, Joe Groff via swift-evolution >>> <swift-evolution@swif

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

... And 30 seconds later I realized that "PureReference" could be fulfilled by something with only static or computed properties. Sent from my iPhone > On May 4, 2016, at 16:16, David Sweeris via swift-evolution > <swift-evolution@swift.org> wrote: > > Havin

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

s, no labels, like so: `static func + (_ lhs: T, _ rhs: > T)`, used like this: `T.+(1, 2)` > * for prefix and postfix operators, a label, like so: `static func + > (prefixing value: T)`, used like this: `T.+(prefixing: 1)` > > > On Mon, May 2, 2016 at 6:26 PM, David Sweeris v

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 10, 2016, at 00:53, Andrew Trick via swift-evolution > wrote: > > >> On May 9, 2016, at 4:07 PM, Matthew Johnson wrote: >> >> I’m also interested in your feedback on whether a proposal around indirect >> is something worth

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

I think I like the idea... However IMHO this really feels like something that should be part of a macro system, not a "proper" language feature. - Dave Sweeris > On Apr 16, 2016, at 08:17, Jonathan Hull via swift-evolution > wrote: > > Since we know the types of

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

-1 for this proposal, but +1 for solving the issues it raises Regardless of what ends up being the defaults, I’m a very strong -1 on conflating visibility and subclassability/extendability. - Dave Sweeris > On Jul 5, 2016, at 6:11 PM, Chris Lattner via swift-evolution >

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On Jul 25, 2016, at 2:28 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky >> > >> wrote: >> >> My one question is, will I be able to

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

Since integers don’t have an implicit logical value in Swift, and since booleans don’t have implicit integer values, why do we need separate operators for concepts that essentially seem (to me, anyway) to only differ by the “bit depth” of the types they operate on? I normally wouldn’t raise

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 4:48 PM, Slava Pestov via swift-evolution > wrote: > > As I understand it, a big weakness of Go's model is that it does not actually > prevent data races. There's nothing preventing you from sharing pointers to > mutable values between tasks,

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

> On Aug 10, 2016, at 5:36 PM, Slava Pestov wrote: > > >> On Aug 10, 2016, at 3:34 PM, Christopher Kornher wrote: >> >> Would this prevent an object from being “known" to multiple threads? >> …multiple queues? If so, it would be overly restrictive for a

Re: [swift-evolution] [Pitch] `Int.init(ObjectIdentifier)` and `UInt.init(ObjectIdentifier)` should have a `bitPattern:` label

+1 Sent from my iPhone > On Jul 13, 2016, at 18:39, Arnold Schwaighofer via swift-evolution > wrote: > > Int.init(ObjectIdentifier) and UInt.init(ObjectIdentifier) should have a > 'bitPattern:’ label to make it clear at the use site that we interpret the > value

Re: [swift-evolution] [Discussion] Allow injection of `didSet` and `willSet`

> On Jul 8, 2016, at 6:45 AM, Adrian Zubarev via swift-evolution > wrote: > > It’s clear that we should decide on when our observer will be executed. In > the example from above I pretended that my observer will be executed after > the observer from the module

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

> On Jul 11, 2016, at 19:13, Jacob Bandes-Storch via swift-evolution > wrote: > > I'd be happy with a warning + fix-it too. > >> On Mon, Jul 11, 2016 at 5:05 PM, Xiaodi Wu wrote: >> Maybe just a warning + fix-it would be sufficient? >> >>> On

Re: [swift-evolution] [Accepted] SE-0115: Rename Literal Syntax Protocols

> On Jul 11, 2016, at 7:34 PM, Jacob Bandes-Storch wrote: > > I'd call it an antipattern: it pretty much defeats the purpose of having the > ExpressibleBy*Literal protocols. > > If you just want a type to be constructible from a value of some other type > (literal or

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I vote for IntegerParkour :-) Sent from my iPhone > On Jun 28, 2016, at 20:35, Erica Sadun via swift-evolution > wrote: > > >>> On Jun 28, 2016, at 6:13 PM, Dave Abrahams wrote: >>> Or we're clueless AND it's a bad name. >> >> It's possible,

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I think +1 on the "nested namespace" idea, unless we'll (no pun intended) literally never use this for anything else. - Dave Sweeris > On Jun 29, 2016, at 01:31, Adrian Zubarev via swift-evolution > wrote: > > How about: > > public enum Syntax { > >

Re: [swift-evolution] [Review] SE-0101: Rename sizeof and related functions to comply with API Guidelines

Would adding a "init(_: T.self) {...}" solve that issue? - Dave Sweeris Sent from my iPhone > On Jun 29, 2016, at 01:54, Dave Abrahams via swift-evolution > wrote: > > My worry is that people will write > > MemoryLayout(Int.self).size > > when they mean > >

Re: [swift-evolution] [Discussion] "try" for function that does not throw

> On Jul 7, 2016, at 12:58, Vladimir.S via swift-evolution > wrote: > > I didn't expect this is allowed(with warning): > > try print("foo") > > (Swift Ver. 3.0 (Jun 20, 2016)) > > Do we really need to allow 'try' for functions that does not throw exceptions?

Re: [swift-evolution] Dropping Comparable requirement for indices

> On Jul 6, 2016, at 20:41, Dave Abrahams via swift-evolution > wrote: > > There is no way, AFAIK, to implement important algorithms like rotate > binarySearch and several others, without having some representation of > position within a collection. Do you need

  1   2   3   4   5   >