Re: [swift-evolution] Move placement of 'throws' statement

Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements. We do need to consider if it restricts future language evolution (such as potentially listing all of the thrown errors), so that’s why it’s relevant to talk a little

Re: [swift-evolution] Move placement of 'throws' statement

> On 27 Dec 2016, at 13:21, Haravikk wrote: > > >> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Daniel Leping, I am unfamiliar with java. Do you have any resources that >> describe the nightmare in detail? > > I think the proble

[swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

Looking for feedback before submitting a PR: https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md — Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer Proposal: SE-

Re: [swift-evolution] Move placement of 'throws' statement

at > might happen in the future, moving the `throws/throwing` to the front would > add a significant amount of noise before the function name. > > > On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I agr

Re: [swift-evolution] Move placement of 'throws' statement

I agree that this could do with revision. It looks particularly ugly when you’re dealing with throwing closures. Recently I had a signature like: public func scan(length: File.ByteOffset.Stride?, by frameSize: File.ByteOffset.Stride, with handler: (_ ran

Re: [swift-evolution] Add ability to validate collection indices

> On 19 Dec 2016, at 04:10, Dave Abrahams via swift-evolution > wrote: > > > on Fri Dec 16 2016, Daniel Vollmer > wrote: > >> Hi, >> >>> On 16 Dec 2016, at 14:56, Alexey Komnin via swift-evolution >>> wrote: >> >> [snip] >> >>> What do you think? I feel

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution > wrote: > > > on Tue Dec 13 2016, Alexey Komnin > wrote: > >> Hi everyone! >> >> I really don't know whether you have discussed it before. So, here is the >> deal. >> >> Currently, Builtin rou

[swift-evolution] Generalised @noescape

Hi I had the need recently to mark a value-type as @noescape, but we only allow that for closure-types. I would like to propose that we allow any parameter to any function to be marked @noescape (by default, unlike closures, they would be potentially-escaping). The standard library has several

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

+1. Sensible change. > On 30 Nov 2016, at 18:15, Nate Cook via swift-evolution > wrote: > > Hello all— > > This is a proposal for a fairly minor change in slicing behavior for unsafe > buffers. > > Nate > > > -- > > > This proposal changes Swift's typed UnsafeBufferPointers to be the

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 30 Nov 2016, at 14:11, Steve Prescott via swift-evolution > wrote: > > As the original poster of this thread, I wanted to re-state the original > question: > > Should enums REQUIRE parameter names? > > Pro: The syntax would more closely match that for functions, which > requir

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 29 Nov 2016, at 18:41, Tony Allevato via swift-evolution > wrote: > > Default values and overloaded cases don't (and in fact, shouldn't) be > conflated. > > I support default values for associated values but I'm not yet ready to say > I'm in favor of overloaded cases. There's no ambigui

Re: [swift-evolution] Require parameter names for ENUM Associated Types?

> On 29 Nov 2016, at 14:55, Adrian Zubarev via swift-evolution > wrote: > > I’d rather would have the ability of overloading enum cases: > > enum MyEnum { > > case a > case a(Int) > case a(label: Int) > case a(Double) > } > I don’t know how enums work internally, but I sp

Re: [swift-evolution] [Discussion] Parameter `vector` keyword vs. triple dot prefix for variadic generics

> On 22 Nov 2016, at 11:08, Adrian Zubarev via swift-evolution > wrote: > > Hello folks, > > I’d like to revive the discussion about the Variadic generics > > feature from the generics manifesto. > > Th

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On 16 Nov 2016, at 18:06, Joe Groff via swift-evolution > wrote: > >> >> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution >> wrote: >> >> >>> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution >>> wrote: >>> On Nov 10, 2016, at 1:30 PM, Dave Abrahams vi

Re: [swift-evolution] Symmetrical operators

> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution > wrote: > > I'm a +1 on the feature, though for simply handling symmetry it's not a super > critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other patterns? For example, could symmetr

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 16 Nov 2016, at 05:25, Shawn Erickson wrote: > > Again my point isn't worrying about point of calling out to the delegate but > configuring my delegator to avoid a body of work or state management that is > unneeded if the delegate doesn't care about some mix of potential delegation > po

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 16 Nov 2016, at 03:42, Charles Srstka wrote: > >> On Nov 15, 2016, at 7:27 PM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> In Objective-C, asking whether or not an object conforms to a protocol just &

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

somewhat heavily in the past and nothing yet has >>> really moved forward on it. I do think a good way of doing something like >>> this would be helpful. I have resulted to defining an interface with an >>> extension that provides empty defaults and for each function

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

way of doing something like >> this would be helpful. I have resulted to defining an interface with an >> extension that provides empty defaults and for each function a match bool >> var exists to imply if it exists or not. The code accepting a delegate can >> probe the

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

missing from most proposed solutions > other then @objc optional). > On Tue, Nov 15, 2016 at 6:59 AM Karl via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>

Re: [swift-evolution] Will Swift ever support optional methods without @objc?

> On 15 Nov 2016, at 12:22, Haravikk via swift-evolution > wrote: > > >> On 15 Nov 2016, at 07:53, Rick Mann via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Nov 14, 2016, at 22:51 , Charlie Monroe via swift-evolution >>> mailto:swift-evolution@swift.org>> wrot

Re: [swift-evolution] [Pitch] Nil struct

> On 9 Nov 2016, at 16:55, Karl wrote: > > If the compiler can’t infer T (such as “let a = nil”), it should fall-back to > Optional.none; I’m very surprised that this isn’t the case currently. > Oh, it is the case currently: let a = nil error: repl.swift:1:9: error: 'nil' requires a contextu

Re: [swift-evolution] [Pitch] Nil struct

-1 Personally, I don’t like writing “nil” at all. In my understanding of Swift, “nil” is simply a C-like shorthand for "Optional.none”. If the compiler can’t infer T (such as “let a = nil”), it should fall-back to Optional.none; I’m very surprised that this isn’t the case currently. There is a

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 2 Nov 2016, at 20:54, Slava Pestov wrote: > >> >> On Nov 2, 2016, at 8:32 AM, Paul Cantrell wrote: >> >> >>> On Oct 24, 2016, at 4:43 PM, Slava Pestov wrote: >>> >>> On Oct 24, 2016, at 8:12 AM, Paul Cantrell wrote: > On Oct 24, 2016, at 5:09 AM, Slava Pestov vi

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 25 Oct 2016, at 00:06, Karl wrote: > > >> On 24 Oct 2016, at 20:23, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> FWIW, in almost all the situations where I’ve wanted to nest types inside >>> protocols and generic types, it’s only as a namespacing

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 24 Oct 2016, at 20:23, Jonathan Hull via swift-evolution > wrote: > >> FWIW, in almost all the situations where I’ve wanted to nest types inside >> protocols and generic types, it’s only as a namespacing convenience. Most >> often, it’s an enum type that’s used only by a single method, a

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

uld not be disallowed. Here is a simple example you might >>>> want to build at some point: >>>> >>>> protocol ProtocolName { >>>> >>>> associatedtype AssociatedType >>>> } >>>> >>>> extension ProtocolName w

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

imple example you might >>> want to build at some point: >>> >>> protocol ProtocolName { >>> >>> associatedtype AssociatedType >>> } >>> >>> extension ProtocolName where AssociatedType == Int { >>> >>> stru

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

might >> want to build at some point: >> >> protocol ProtocolName { >> >> associatedtype AssociatedType >> } >> >> extension ProtocolName where AssociatedType == Int { >> >> struct InnerType {} >> } >> >

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Oktober 2016 um 20:30:58, Karl via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> Is your vision that each conforming type would have to provide its

Re: [swift-evolution] Import Conditionals

I disagree. What about when you need to disambiguate? Currently you’d need to use ‘Darwin.connect(...)’ or ‘Glibc.connect(…)’. Merging them both in to one ‘Libc’ module would make that much easier. > On 18 Oct 2016, at 01:07, Sean Alling via swift-evolution > wrote: > > Yeah I saw that thread

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

> On 17 Oct 2016, at 20:31, Adrian Zubarev via swift-evolution > wrote: > > That’s also on the line: > [https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics > >

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

enum RoundingRule : _RoundingRule { func round(_ val: Float) -> Float { /* switch self, perform rounding… */ } } } That brings up an interesting point, though - we would need a way to refer to the outer protocol (I used “Super” here). > > Nevin &g

[swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I was just doing some googling, turns out there was a discussion about nesting protocols in other types that seemed to go positively a long time ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html

Re: [swift-evolution] Tuples as RawRepresentable

> On 16 Oct 2016, at 00:33, Haravikk via swift-evolution > wrote: > > >> On 15 Oct 2016, at 18:21, Nevin Brackett-Rozinsky >> mailto:nevin.brackettrozin...@gmail.com>> >> wrote: >> >> Tuples cannot conform to protocols, so despite the existence of an “==” >> operator for certain tuples, no

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

Done. https://bugs.swift.org/browse/SR-2963. > On 14 Oct 2016, at 22:42, John McCall wrote: > >> On Oct 11, 2016, at 12:04 AM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> >>> On 11 Oct 2016, at 08:49, Benjamin Sprat

Re: [swift-evolution] Tuples as RawRepresentable

> On 14 Oct 2016, at 19:56, Haravikk wrote: > > Huh, see, that's why I posted the thread; I didn't know you could do it that > way (I've been trying the RawRepresentable part as its own type). > In that case yes, it seems like all that's need is an expansion of what's > allowable on the rhs of

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

> My point is that, IMO, this is all I want. Thus what I’m implying is that > there’s probably not any ABI impact to (IMO) “fix” enums with associated > values, and so I don’t know why this discussion keeps going on and veering > into (what seems to me to be) overly complex territory when many o

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

I disagree. I find the first better in a number of respects (although there are certainly things you could do to optimise legibility). Firstly, I can more clearly see all of the various file errors. I can easily see how many there are, which associated values they take, etc. That’s important wh

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

> On 12 Oct 2016, at 18:44, Mateusz Malczak wrote: > > I got a bit confused, I think we are here talking about completely > different features. Lets take a look at example from Karl > >> enum Something { >> case oneThing(UIView) >> case anotherThing(Error) >> case yetAnotherThing(Int) >>

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

appropriate, it always takes me 4 or 5 attempts to get the incantation correct (single equals!): if case .anotherThing(let theError) = myValue { print(“oh, no! an error! \(theError)”) } Urf. - Karl > On 12 Oct 2016, at 17:12, Xiaodi Wu wrote: > > > > On Wed, Oct 12, 2016 at 10:

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

Not at all - his proposal looks like the enum cases have an associated value, when that is exactly what you _don’t_ want. It’s wasted storage because they have a handful of known values. It’s a PITA, I get it, I go through it all the time, too; but really this is the very definition of a comput

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

You can already use structs as raw types. You just have to implement the RawRepresentable conformance yourself. RawRep doesn’t affect the enum’s storage, and the shorthand syntax we’ve got saying “case a = 42” and so on is just for the compiler to synthesise a couple of switch statements. The o

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

I very much disagree with the proposal, and all of the things supporting it (like deriving enums from other types and whatnot). I think you need to take a step up from caring about whether it’s a struct or enum and think about what you are trying to model; that will guide you towards the correct

Re: [swift-evolution] stored properties in extensions (was: associated objects)

> On 10 Oct 2016, at 21:15, Charles Srstka via swift-evolution > wrote: > > Right. The question is whether we *need* to add stored properties > out-of-module, and what the use case for that is. To me it seems that adding > them in-module is by far the more common use case, for the purposes of

Re: [swift-evolution] [Pitch] Change location of 'try' for infix operators

> On 11 Oct 2016, at 08:49, Benjamin Spratling wrote: > > Howdy, > The error message is not saying that aFunction throws, it says “??" might > throw. After all, you supplied a ()rethrows->(Int) to it as its second > argument, which is wrapping a ()throws->Int, “bFunction()" > ?? and && and ||

[swift-evolution] [Pitch] Change location of 'try' for infix operators

You might expect this code to work: func aFunction() -> Int? { return 5 } func bFunction() throws -> Int { return 4 } let value = aFunction() ?? try bFunction() // ERROR: Operator can throw but expression is not marked with a ‘try' print(value) Instead, you must put the ‘try’ before the e

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 21:01, Xiaodi Wu wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On 8 Oct 2016, at 16:47, Braeden Profile > <mailto:jhaezhy...@gmail.com>> wrote: >> >&g

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 16:47, Braeden Profile wrote: > >> >> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I was thinking that the domains themselves could be associated with a >> domain,

Re: [swift-evolution] private & fileprivate

exibility without - I > think - the IMHO quirkiness of friends in C++. It seems like the access > domains must? be limited to inside a module to avoid potential surprises from > outside the module? > > -Shawn > > On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution >

Re: [swift-evolution] associated objects

> On 28 Sep 2016, at 17:26, Jay Abbott via swift-evolution > wrote: > > I have implemented Associated Objects (and values) in pure swift here: > https://github.com/j-h-a/AssociatedObjects > > > The README is very short and straight-forward so I won

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

It’s one of those issues where everybody agrees we could do better but nobody cares enough to do anything about it. In any case I think Discourse seemed to be the only real option because of mailing-list support. So I suppose they next step would be to submit a formal proposal to swift-evo on G

Re: [swift-evolution] private & fileprivate

> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution > wrote: > > >> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution >> wrote: >> personally I thought `private` was fine the way it was when it meant >> `fileprivate` and I had no real need for `private` as it exists in Swift 3.

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

> On 27 Sep 2016, at 18:55, Joe Groff via swift-evolution > wrote: > > >> On Sep 26, 2016, at 8:51 AM, Jérôme Duquennoy via swift-evolution >> wrote: >> >> Summary >> The aim of this proposal is to offer a new syntax to ease some uses of enums >> with payload. >> >> Situation to improve:

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> On 14 Sep 2016, at 18:08, Andrew Trick via swift-evolution > wrote: > > >> On Sep 10, 2016, at 5:53 PM, Andrew Trick wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md >> >> The review period has been extended until September 14. The

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

> On 25 Sep 2016, at 21:45, Drew Crawford wrote: > >> I think this is already part of the Generics Manifesto: >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md >> > So is this proposal. The proposal's

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

> On 24 Sep 2016, at 21:58, Drew Crawford via swift-evolution > wrote: > > This is the #1 Swift feature I have wanted for the past 2 years. > > One thing I would like to see (perhaps out of scope for this proposal) is the > natural extension for generic parameters: > > struct Box { > var

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

> What is your evaluation of the proposal? +1. Can’t wait. > Is the problem being addressed significant enough to warrant a change to > Swift? -_- > Does this proposal fit well with the feel and direction of Swift? Sure does > If you have used other languages or libraries with a similar featur

Re: [swift-evolution] Source-breaking proposals?

> On 25 Sep 2016, at 18:38, Anton Zhilin via swift-evolution > wrote: > > Do I miss something, or proposals with source-breaking changes still can't be > submitted? > When will corresponsing guidelines be out? Are there any plans on that matter? > __

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

No the proposal seems to be about unicode characters in Swift source code: To ease lexing/parsing and avoid user confusion, the names of custom identifiers (type names, variable names, etc.) and operators in Swift can be composed of (mostly) separate sets of characters. In that sense, it sounds

Re: [swift-evolution] Mark protocol methods with their protocol

I would like to make it a requirement if not inside a protocol extension which declares a conformance, and actually build the protocol name in to the member in an ABI-breaking way. We could make it additive by generating forwarding thunks from the old symbols to the new ones, but it would be bet

Re: [swift-evolution] Mark protocol methods with their protocol

e main body (or we loosen >>> that to at least extensions in the same file). >>> >>> ``` >>> // generates thunks to members of this extension in the base type; >>> // so MyComplexDataType.count —> MyComplexDataType.InternalStructure.count, >

Re: [swift-evolution] Mark protocol methods with their protocol

d in later version. Can also be used >> for renamed protocols, and be tagged on individual members. >> >> @makeAvailable(as: _) >> extension MyComplexDataType : InternalStructure { >> >>typealias Index = InternalIndexType >> var count : Int {

Re: [swift-evolution] Mark protocol methods with their protocol

t; // Also, we get errors about non-conformance where we want them — > where the implementation is. > } > func doInternalMagic(at: Index) { >... > } > } > ``` > >> On 20 Sep 2016, at 23:46, Xiaodi Wu > <mailto:xiaodi...@gmail.com&g

Re: [swift-evolution] Mark protocol methods with their protocol

> On 21 Sep 2016, at 00:08, Vladimir.S wrote: > > On 21.09.2016 0:28, Karl via swift-evolution wrote: >> > > I don't understand. Do you feel that this: > > class MyClass : MyProto { >var MyProto.aVariable : Int >func MyProto.aFunction() { … }

Re: [swift-evolution] Mark protocol methods with their protocol

the implementation is. } func doInternalMagic(at: Index) { ... } } ``` > On 20 Sep 2016, at 23:46, Xiaodi Wu wrote: > > I'm not sure I understand. What compiler or language support is missing for > StringCore? > On Tue, Sep 20, 2016 at 16:42 Karl via swift-evolution &

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 23:28, Karl wrote: > > >> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I have been following this discussion (as well as similar threads earlier >> this year) and listening to the ideas put forth

Re: [swift-evolution] Mark protocol methods with their protocol

> On 20 Sep 2016, at 18:43, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > I have been following this discussion (as well as similar threads earlier > this year) and listening to the ideas put forth by all sides. > > It seems to me that the fundamental difference between classes and

Re: [swift-evolution] Mark protocol methods with their protocol

I started putting together a proposal, hopefully better explaining what I’m suggesting: https://github.com/karwa/swift-evolution/blob/patch-2/-template.md > On 17 Sep 2016, at 05:32, Xiaodi Wu wrote: > > On Fri, Sep

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 05:32, Xiaodi Wu wrote: > > On Fri, Sep 16, 2016 at 20:28 Karl > wrote: >> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> > >> I absolutely agree that it's a problem worth solving. Howeve

Re: [swift-evolution] Mark protocol methods with their protocol

> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution > wrote: > > I absolutely agree that it's a problem worth solving. However, the question > is whether a particular proposed design solves the problem and avoids > previously stated weaknesses. What I'm saying here is that, so far, the

Re: [swift-evolution] [Pitch] mutable `newValue` in willSet

;var newValue". In fact, what you're actually >> proposing isn't even the equivalent of "var newValue"; it's to have newValue >> be of type `inout T` instead of `T`. I think such an implicit inout has no >> precedent in Swift and would be confusing

[swift-evolution] [Pitch] mutable `newValue` in willSet

Sometimes you would like to modify the value being set to a property before it is set. Currently, you would have to add a separate backing property and implement the getter and setter, even if you want to perform a simple bounds-check on the value being set and want to cap it to allowed values.

Re: [swift-evolution] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

I know the review is over, but I just wanted to chime in with something: does this extend to types which are RawRepresentable as numeric types, too? For example, Cocoa and UIKit have several option-set types which must be placed in dictionaries. Just now I tried to use UIFontDescriptorSymbolicT

Re: [swift-evolution] Class scoped access level

> On 10 Sep 2016, at 14:16, T.J. Usiyan via swift-evolution > wrote: > > I am firmly against this. The 5 levels that we have cover us well and have > enough complexity already. You can say that again! It seems the compiler has become much stricter about it very recently. I was recently writ

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

> > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a >change to Swift? Yup > * Does this proposal fit well with the feel and direction of Swift? Yes, but I’m not sure about the “Unsafe” part of “UnsafeBytes” — what is uns

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 2 Sep 2016, at 06:14, Xiaodi Wu wrote: > > Run loop modes are named by string, and as you can see in your link, > comparisons of run loop modes are by their raw value--i.e. by string. While > it's of course sensible to have a total ordering for strings, I'm skeptical > that you would typ

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 31 Aug 2016, at 15:53, Xiaodi Wu wrote: > > Comparable makes semantic guarantees about how values of conforming types > might be ordered. You don't need `min` or `max` for that to be useful, since > it's trivial to implement using comparison operators. > > Basic numeric types require com

Re: [swift-evolution] PITCH: Return a subclass for a protocol method without the need for an associatedtype

> On 31 Aug 2016, at 06:10, Sitton, Yogev via swift-evolution > wrote: > > That’s was my point. > Two sets of rules for the same case in two different places. > These should be unified. > > I’ll write the proposal and create a pull request. > >> On Aug 17, 2016, at 11:24 PM, Slava Pestov >

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution > wrote: > > As an additive proposal, I don't think this would be in scope for the current > phase of Swift 4. > > Looking forward, though, I'm not sure this belongs in the standard library. > In general, my understanding is that Swif

Re: [swift-evolution] [Late Pitch] open/public protocols

This is not a new inconsistency. We’ve known about this since “open” was first proposed. Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Karl > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution > wrote: > > Hello dear Swift community, > > I was updating

Re: [swift-evolution] Renaming for Protocol Conformance

> On 24 Aug 2016, at 20:38, Douglas Gregor via swift-evolution > wrote: > >> >> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi everyone, >> >> We talked about this before when we were discussing mixins, and there seemed

Re: [swift-evolution] [Pitch] Require Any for existentials

> On 24 Aug 2016, at 00:14, Adrian Zubarev via swift-evolution > wrote: > > The basic design is fine, but I wouldn't want to add more noise to my code. > We could keep (label: Protocol) as a shorthand form for (label: > Any) similar to Optionals. > > What's the benifite of this anywasys? Wha

Re: [swift-evolution] Renaming for Protocol Conformance

> On 23 Aug 2016, at 07:39, Karl wrote: > > >> On 23 Aug 2016, at 06:59, Jonathan Hull via swift-evolution >> wrote: >> >> Hi everyone, >> >> We talked about this before when we were discussing mixins, and there seemed >> to be generally positive feelings towards it as a feature for the fu

Re: [swift-evolution] Renaming for Protocol Conformance

> On 23 Aug 2016, at 06:59, Jonathan Hull via swift-evolution > wrote: > > Hi everyone, > > We talked about this before when we were discussing mixins, and there seemed > to be generally positive feelings towards it as a feature for the future. I > am fairly certain this affects the ABI tho

Re: [swift-evolution] [Idea] Typed Numerics

> On 22 Aug 2016, at 18:17, Charlie Monroe via swift-evolution > wrote: > > I've personally come across something like Nur suggested. In particular, this > is with NSTimeInterval, which is a typedef for Double. > > What I wanted to do is to make > > extension NSTimeInterval { > static

Re: [swift-evolution] Swift Package Manager 3.0 Project Status

> On 18 Aug 2016, at 03:04, Keith Smiley via swift-evolution > wrote: > > It sounds like we may not get any heads up about any work on that level of > integration: > > https://twitter.com/jckarter/status/766072626624073729 > > Which I guess also brings up the question of whether or not it wil

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

> On 19 Aug 2016, at 19:35, Andrew Trick wrote: > > >> On Aug 16, 2016, at 7:13 PM, Karl via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution >>> mail

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

> On 11 Aug 2016, at 07:18, Chris Lattner via swift-evolution > wrote: > > >> On Aug 10, 2016, at 8:15 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I don't know if the core team feels differently now with respect to Swift 4, >> but union types are lis

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

> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution > wrote: > >> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution >> wrote: > >> >> It seems like there’s a potential for confusion here, in that people may see >> “UInt8” and assume there is some kind of typed-ness,

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution > wrote: > >> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Aug 16, 2016

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

> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution > wrote: > > Hi folks, > > I see from building the latest Swift-3.0 branch that I’m a little behind the > times and this proposal has been accepted :( > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-p

Re: [swift-evolution] Swiftier implementation of Measurement and Unit

> On 11 Aug 2016, at 00:51, Xiaodi Wu via swift-evolution > wrote: > > Probably swift-corelibs-dev would be the forum for that? IIUC correctly, > though, the current goal for corelibs-foundation is to vend the exact same > API as Apple Foundation. I'd also be curious as to when it would be >

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

> On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution > wrote: > > > Hi Everybody, > > With another round of apologies for taking late action, we propose to > make some deprecations, moves, and renames. The background for these > moves is as follows: > > We've always known that when

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

> On 8 Aug 2016, at 04:18, Dave Abrahams wrote: > > > on Sun Aug 07 2016, Karl > wrote: > >>> * What is your evaluation of the proposal? >> >> +1 >> >> Although if I was nitpicking I prefer the name “ofInstance” (as in the >> stdlib private function) to “o

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

> * What is your evaluation of the proposal? +1 Although if I was nitpicking I prefer the name “ofInstance” (as in the stdlib private function) to “ofValue”. What is the standard nomenclature? Whereas I would distinguish between “objects/instances” and “values”, I’ve started referring

Re: [swift-evolution] Swift 3.1 discussions, go?

> On 3 Aug 2016, at 05:29, Chris Lattner via swift-evolution > wrote: > > If you see such a drastic slowdown, then tat sounds like a critical > regression that you found in the latest beta. We would really appreciate a > bug report (radar or jira) with a testcase! > > -Chris Aside: is ther

Re: [swift-evolution] MemoryLayout for a value

> On 6 Aug 2016, at 11:05, Adrian Zubarev via swift-evolution > wrote: > > What’s so confusing about MemoryLayout.size? > > size in this context gives you the size for the metatype of T, not the size > of T. > > If I memorize correctly: > > Size of metatypes of value types and functions/clo

Re: [swift-evolution] MemoryLayout for a value

> On 4 Aug 2016, at 06:27, Dave Abrahams via swift-evolution > wrote: > > > on Wed Aug 03 2016, Xiaodi Wu > wrote: > >> Why not just MemoryLayout.init(of instance: T), and drop the autoclosure >> magic altogether? > > My proposal *does* drop the autoclosure m

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On 2 Aug 2016, at 11:07, Tino Heth via swift-evolution > wrote: > >> I would love to have a great web archive for swift-evolution—something with >> a really solid search function, good threading, and most of the other >> niceties of forums. It'd even be nice to have an upvote feature. But t

  1   2   >