Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

A strong +1 on this approach instead of the current revision of SE-0194. This is a very focused solution to a very focused need. It sidesteps the issues of a protocol based approach (potential for abuse or deciding/defining the intended uses of such protocol). Also, we already have the underpinn

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

For people who don’t read all the way down, here is the gist of what Chris is saying: > 1. The vast majority of the standard library goes into the OS. This includes > all the string, array, and other stuff people use. > 2. The deprecated wrappers and obscure APIs go into a new module, and that

Re: [swift-evolution] Incremental ABI stability

I think the best solution is Chris Lattner’s suggestion (responding to DictionaryLiteral) to split the shaky stuff into an overlay for Swift standard library to maintain compatibility. > On Jan 10, 2018, at 2:12 PM, Greg Parker via swift-evolution > wrote: > > >> On Jan 9, 2018, at 6:50 PM,

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

Excellent Idea! I am all for this. It shouldn’t be too complicated to add a second implicit import and only code that is actually using this stuff will have increased code size. > On Jan 9, 2018, at 10:29 PM, Chris Lattner via swift-evolution > wrote: > > Disclaimer: I’m reordering your comm

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

I think this type might become more useful if we find a good name for it and better document it. For example, it is a natural fit for parameter list of Chris’ callable type proposal. Since this type accepts duplicate “keys” and does not provide key-based lookup, the first thing that deserves a

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

;> init() >>> } >>> >>> extension P where Self : Initable { >>> mutating func f(_ x: Int) -> Int { >>> self = Self() >>> return x >>> } >>> } >>> >>> class C : P, Initable { >>

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

let x: P & AnyObject > > x.f(12) > > This would be invalid because ‘x’ is a let binding but the requirement ‘f’ is > witnessed by the protocol extension method, which performs a mutating access > of ‘self’. > > Slava > >> On Dec 21, 2017, at 6:01 PM,

[swift-evolution] Preserving non-mutability of methods of an existential or generic object

The title is confusing, let me clarify by example: We have this protocol with a mutating method: protocol P { mutating func f(_ x: Int) -> Int } And a conforming class (which has to conform with a non-mutating method): class C: P { func f(_ x: Int) -> Int { return x } } An instance of this cla

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

+1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it. > On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution > wrote: > On Nov 22, 2017, at 9:48 AM, Chris Lattner > wrote: > >> IMO this is obvious and you should put it in. >> >> Th

Re: [swift-evolution] Adding Result to the Standard Library

ue(try closure()) } catch { self = .error(error) } } > On Nov 14, 2017, at 6:57 PM, Hooman Mehr via swift-evolution > wrote: > > You can support all styles with enum as well. What don’t you do this: > > public enum Result { > > case v

Re: [swift-evolution] Adding Result to the Standard Library

You can support all styles with enum as well. What don’t you do this: public enum Result { case value(T) case error(Error) public init(_ value: T) { self = .value(value) } public init(error: Error) { self = .error(error) } public func get() throws -> T { swit

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

+1 It should have been like this from the get go. > On Nov 14, 2017, at 11:31 AM, Ted Kremenek wrote: > > The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now > and runs through November 21, 2017. > > The proposal is available here: > > https://github.com/apple/swift-

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Remove ownership keyword support in protocols

+1 After a quick read, I don’t think this issue needs a review: It is just a compiler bug. > On Sep 20, 2017, at 1:11 PM, Ted Kremenek wrote: > > The review of “SE-0186: Remove ownership keyword support in protocols” begins > now and runs through September 27. > > The proposal is available h

Re: [swift-evolution] Different types for getter and setter

These types of unusual property behaviors could be implemented if we had property behaviors proposal revised and implemented. How about resurrecting this for Swift 5.x? I think it will also be a use

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

Thank you Pierre for writing this. I wanted to say this for a while, but I am too busy these days to do it myself. Guys, please don’t miss what he has to say: > On Aug 31, 2017, at 5:49 PM, Pierre Habouzit via swift-evolution > wrote: > > On real systems going wide concurrently (and I will n

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Maybe we need more than one level of standard library: The core (which is most of what we have now (but maybe not all of it) and multiple opt-in standard modules for hash functions, math, specialized data structures, etc. > On Jul 31, 2017, at 11:10 AM, Taylor Swift wrote: > > I’m not sure why

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I know. I hear you. I have some special arrangmnents to keep such things manageable, and I am not happy about how things stand right now. What I am hoping to open up stdlib special compiler mode to other (low-level) libraries and also letting such libraries gain optimizations similar to stdlib

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I prefer an approach that preserves how I am used to seeing math expressions. I use this myself: protocol FloatingPointMath: FloatingPoint { static func sqrt(_ value: Self) -> Self static func sin(_ value: Self) -> Self static func cos(_ value: Self) -> Self static func tan(_ val

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

I like this promote operator idea. I have been defining similar operators for specific projects almost at random. It makes sense to come up with a well-defined behavior and name for such operators, as a common practice as you suggest. The problem with the postfix operator is that it does not cu

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Considering these observations and more from Brent and Dave, I support ultimately making KeyPath) a subtype of (T)->U as suggested. If someone really wants this now, I would go with a prefix operator as a stopgap: prefix operator ~ prefix func ~(lhs: KeyPath) -> (T)->U { return { $0[keyPath: l

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

Overall, I am strong +1 on this, but I don’t have time to go through a detailed analysis of how it will affect my own use cases. > On Jun 4, 2017, at 4:29 PM, Ted Kremenek via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0180 "String Index Overhaul" begins now and

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jun 06 2017, Brent Royal-Gordon > wrote: > >>> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu wrote: >>> >>> Why would this be an extension on UnsafePointer and not KeyPath? >>

Re: [swift-evolution] [Pitch] Computed properties as aliases

Agreed. Actually, I was thinking about it while writing my response and wanted to go back and dig that thread to refresh my memory and bring it up. Thank you for taking care of that. > On May 25, 2017, at 7:33 PM, Charles Srstka wrote: > >> On May 25, 2017, at 9:26 PM, Hoo

Re: [swift-evolution] [Pitch] Computed properties as aliases

This is common when you are using façade design pattern. You use a façade to flatten and hide the internal composition of a composite object and present it as a single flat object. In some types of projects this comes up rather frequently. Both in client / UI programming and server side / busine

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

+0.5 Positive on multi-line string literal Negative on the delimiter. I don’t like continuation character, but would like to have something similar to classic C comments: distinct, symmetrical opening and closing delimiters. But I don’t have any specific suggestion. > On Apr 7, 2017, at 11:3

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

+1 with this clarification / revision > On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution > wrote: > > >> On Apr 5, 2017, at 10:32 PM, Félix Cloutier > > wrote: >> >> During the proposal phase, we asked how this would handle fixed-length >> strings with an o

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1 Having the feature is worth the oddities of the syntax. > On Apr 5, 2017, at 4:01 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > >

Re: [swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

Agreed. +1 > On Apr 6, 2017, at 11:51 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md > >

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

> On Mar 29, 2017, at 3:00 PM, Douglas Gregor via swift-evolution > wrote: > > > * @implicitobjc added to a class implicitly makes members of that class *and > all of its subclasses* @objc if they can be exposed to Objective-C > * @implicitobjc added to a class extension makes members of that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

Similar observation on my side as well. Certainly it is better to specify the class constrain (or the type alias that has the class constrain) first because (sub)class constrain is the most determining factor about the nature of the declaration, but I think it is too hard to enforce properly whe

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md > > ] > > Well-

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

+1, basically the same response as Matt’s. > On Feb 28, 2017, at 1:51 PM, Matthew Johnson via swift-evolution > wrote: > >> >> What is your evaluation of the proposal? > +1. Checking things off the list of items on the generics manifesto is > always great to see, especially when they allow f

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

By its classic definition, a function that has inout parameters is not pure. So, again by classic definition, it should have a return value to have any use. But things can quickly get murky if we try to enhance and extend the meaning of pure. Then it becomes important to see at what level of abs

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 1:24 AM, Slava Pestov via swift-evolution > wrote: > >> 3. When a protocol composition type contains a typealias, the validity of >> the type is determined using the following steps: >> >> Expand the typealias >> Normalize the type by removing duplicate constraints and r

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 6:50 PM, Shawn Erickson wrote: > > > > On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr > wrote: >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams > > wrote: >> >> >> on Thu Feb 09 2017, "Ted F.A. van Gaalen" >

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: > >> Hello Shawn >> Just google with any programming language name and “string manipulation” >> and you have enough reading for a week or so :o) >> TedvG > > That truly doesn't answer th

Re: [swift-evolution] Nil-rejection operator

Two more tiny overloads is all takes to fix it: func ??(lhs: T?, rhs: T) -> T { if let lhs = lhs { return lhs } else { return rhs } } func ??(lhs: T?, rhs: U) -> Error { if let lhs = lhs { return lhs } else { return rhs } } > On Feb 9, 2017, at 12:01 PM, Jack Newcombe wrote:

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution > wrote: >> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> Looks good. Minor comments below: >> The typealias 'T5' is repeated as both an initial composition, and as a

Re: [swift-evolution] Nil-rejection operator

I think the best solution is overloading the existing ?? operator. It is very easy to do: func ??(lhs: T?, rhs: U) throws -> T { if let lhs = lhs { return lhs } else { throw rhs } } then you can say: do { let y = try x ?? myError } catch ... It might even make sense to a

Re: [swift-evolution] Strings in Swift 4

> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > I now assume that: > 1. -= a “plain” Unicode character (codepoint?) can result in one > glyph.=- What do you mean by “plain”? Characters in some Unicode scripts are by no means “plain”. They can affect

Re: [swift-evolution] It's the little things..

> On Dec 14, 2016, at 11:08 AM, David Sweeris via swift-evolution > wrote: > I'll be curious as to how they propose we prevent collisions between > Optional.none.hashValue and any given T's hash value. It is a hash, collision is fine. It is just a single value. I guess a hashValue of zero w

Re: [swift-evolution] Generic types―covariance/contravariance

onal also benefit > from variance: > > func p(_ data:Any?) { > if data != nil { > data.map { print($0) } > } > } > var a:String? = "foo" > p(a) > // -> “foo" > > > -DW > >> On Dec 9, 2016, at 12:24 PM, Hooman Mehr via s

Re: [swift-evolution] Generic types―covariance/contravariance

For the specific case of custom collections, I think it is worth providing a protocol as Doug noted before. Quoting Doug Gregor (1/13/16, thread: "Make generics covariant and add generics to protocols”): > Swift’s value-semantic collections are covariant in their generic parameters, > which we

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

How about providing an Int subscript in addition to switching the index type for the purpose of Subsequence? > On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution > wrote: > > >> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>

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

+1 on the third option it being clearly the best way to model pointers. Making the index strideable makes its use in index computations easy. It takes a bit care to make it work as conveniently for UnsafeBufferPointer where the stride will need to be special. > On Dec 1, 2016, at 11:33 PM, Nat

Re: [swift-evolution] Implicit Optionals for Tuples & Tuples as Function Parameter

Since Swift 3.0, they are no longer a normal type like Optional. See SR-0054 > On Nov 11, 2016, at 11:54 AM, Muhammad Tahir Vali via swift-evolution > wrote: > > Im curious to know the reasoning behind why imp

Re: [swift-evolution] [Review extended] SE-0143: Conditional Conformances

+1. This is the best we can do for now, given time and resources. > On Nov 9, 2016, at 4:03 PM, Joe Groff via swift-evolution > wrote: > > During the first round of review for SE-0143, there was concern about the > clarity of the proposal as written, since the discussion fixated on a number

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

> On Nov 6, 2016, at 8:03 PM, Dave Abrahams via swift-evolution > wrote: >> I had a brush with Julia > as >> well. Have you >> looked at their work > > It's been a while, to be honest. > >> and the recent reworking of their similar data structure

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

Yes, this is a very important issue to consider before we freeze them. As part of my Swift hobby, I have worked a bit on a Swifty wrapper for linear algebra packages and also toyed a bit with the merits of a Swift implementation of some of the related algorithms and data structures (such as band

Re: [swift-evolution] guard let x = x

> On Nov 2, 2016, at 2:02 PM, Matthew Johnson via swift-evolution > wrote: >> On Nov 2, 2016, at 3:47 PM, Sean Heber via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> For what it’s worth, I concur. I think type narrowing makes it feel more >> like the language is actually

Re: [swift-evolution] Some clarity lost from the great renaming

Is changing the mapping of Cocoa API considered a source breaking change or can we report such incidents as bugs if we think they don’t match API guidelines? > On Oct 18, 2016, at 6:43 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Oct 18 2016, Brandon Knope

Re: [swift-evolution] [Pitch] Adding in Optional Argument labels for completion handlers

This is an unfortunate side effect of another important and necessary change: Making argument labels part of functions name. This means that closures (which are anonymous functions and lack a function name) now don’t have any place to keep the argument labels. Using a labeled tuple as a single

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

I don’t think $ will be become available to be used as an operator if we remove its identifier use. > On Oct 14, 2016, at 1:49 PM, Daniel Duan via swift-evolution > wrote: > > Agree with Robert here. I'd rather be able to use it as part of operators. > Currently the character set for operato

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

+1. I am in favor of keeping and documenting single dollar sign as a valid identifier. I personally find it very convenient to have it as a valid identifier, although I don’t use Dollar library. > On Oct 14, 2016, at 12:59 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of

Re: [swift-evolution] private & fileprivate

fileprivate is not essential but I also would like to defend keeping it, at least for now. I find it useful in practice. In some cases, I can’t put a declaration in the global file scope (where fileprivate and private are essentially the same thing). For example, for organizational reasons I

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

Strong +1. I really need this feature to improve and simplify my existing code. > On Sep 23, 2016, at 5:50 PM, Austin Zheng via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1. I very much want to see this in Swift, and it seems like a logical > progression tha

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

> * What is your evaluation of the proposal? +0.5 > * Is the problem being addressed significant enough to warrant a > change to Swift? Almost > * Does this proposal fit well with the feel and direction of > Swift? I am not totally happy with the whole Memor

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

+1 Same answers. > On Jul 15, 2016, at 10:54 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > * What is your evaluation of the proposal? > > +1 > > * Is the problem being addressed significant enough to warrant a > change to Swift? > > Yes, minor but important. >

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

How about we get rid of dynamicType by adding instance level properties as well: public struct MemoryLayout { public static var size: Int { return sizeof(T) } public static var interval: Int { return strideof(T) } public static var alignment: Int { return alignof(T) } pub

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

26, 2016 at 11:11 AM, Hooman Mehr via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Syntax by itself is not clear enough. Appending Initializable makes it too > long. > > We can replace Syntax with LiteralSyntax to clarify. Then we will have: > >

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

Syntax by itself is not clear enough. Appending Initializable makes it too long. We can replace Syntax with LiteralSyntax to clarify. Then we will have: extension MyNumber: LiteralSyntax.Integer, LiteralSyntax.Float { /*…*/ } Better yet, to address the valid concern of doing something so diffe

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

On Jun 4, 2016, at 4:58 PM, Hooman Mehr via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> How about this: >> >> >> Going back to Erica’s original example: >> >> func scaleAndCropImage( >> image: UIImage

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

How about this: Going back to Erica’s original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, operation: (.Fit | .Fill) = .Fit ) -> UIImage { And noting that we are already allowed to declare an enum inside the function, compiler can generate an enum sco

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

This arises a different question: Should `description` always return the same value? For example: Can `description` of “May 31th, 2016” return “Today” if we evaluate it today and return “Yesterday” if we evaluate it tomorrow? Are such side-effects (using a volatile global value) permitted? Then

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

Correction/ Clarification. My assumption. The signature I am assuming is actually: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = false ) -> UIImage { > On May 31, 2016, at 3:27 PM, Hooman Mehr via swift-evolution > wrote: > > I

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

If we go back to your original example: func scaleAndCropImage( image: UIImage, toSize size: CGSize, fitImage: Bool = true ) -> UIImage { There is a different type of sugar that I would like to have: Having label stand for `true` when we have a defaulted boolean flag, whose def

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Exactly what I feel about this. I am prepared to go as far as disallowing: let x = optionalX, y = optionalY syntax to free up comma for use instead of semicolon. Then the above becomes: let x = optionalX, let y = optionalY In this case we will keep the comma at the end of the line as well.

Re: [swift-evolution] [Proposal] Shorthand Argument Renaming

I prefer keeping $ as a valid character for identifiers. Moreover, such a change will break a lot of client code other than closures (where it can be auto-migrated). > On May 31, 2016, at 2:51 AM, James F via swift-evolution > wrote: > > Moreover, this would free up $ as an operator. I'm for

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

Exactly: I also consider synchronous dispatch a special case not worthy of sacrificing a better name (`dispatch`) for it. I prefer to have a single `dispatch` as the main function name. Here is my proposed modified signature based on the proposal

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

How about a more radical change that eliminates this entire concern and keeps the whole generics declarations in one place: Move the entire generic declaration with its brackets somewhere other than between function name and its parameters. I know this breaks the “norm”, but what do you think?

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

Thank you for your comments. I think additional index manipulation and collection scanning API is needed, and your proposal cover an important part of it. I also have some clarifications and comments inline: > On May 10, 2016, at 4:52 PM, Nate Cook wrote: > Thanks Hooman! Those do look like u

Re: [swift-evolution] [RFC] #Self

> On May 10, 2016, at 2:49 PM, Matthew Johnson via swift-evolution > wrote: >> That said, I’m not sure I understand the concrete use-cases. When is this >> concept important? When is “Self” not good enough? > > The only case where there is new functionality is when this is used in a > proto

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

Although handy for now, I am a bit concerned about moving `where` clause to the end of declaration. This reserves and occupies this wide open space at the end of declarations. I think we might find a better use for this space later as the language evolves. Any thoughts? > On May 10, 2016, at 1

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

I agree with adding more such API’s. Look at this gist for an implementation of a few more of what I find useful. You can add them to your proposal if you like them and I will be able to help better shape it up. Here is a summa

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

Besides the ages old designated initializer pattern that is already suggested (having a few designated initializers and a bunch of convenience initializers), this is how I have been dealing with this since Swift 1.0: import UIKit import AVFoundation class SomeViewController: UIViewController {

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0048: Generic Type Aliases

Strong +1 from me, too. With the exact response as Juan. It is among the top 10 on my wish list. > On Mar 24, 2016, at 11:18 AM, Juan Ignacio Laube via swift-evolution > wrote: > > What is your evaluation of the proposal? > A strong +1 on this. > > Is the problem being addressed significant e