Re: [swift-evolution] Specified Protocol Conformances in Subclasses

Looks like a compiler bug, since it works with classes: class Base {}class Derived : Base {} class A { var x: Base? { return Base() } } class B : A { override var x: Derived? { return Derived() } } ​ ___ swift-evolution mailing list

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

I disagree with dropping function references in general, but I do agree with limiting partially applied method references. In @escaping arguments, adding self. won’t add enough evidence that it actually creates a closure with capture. Even in non-escaping context, I find plain method references

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

2017-03-03 2:13 GMT+03:00 Slava Pestov : Does newtype add any new capability that’s not already covered by defining > a struct? > newtype would forward all members and conformances of the underlying type: newtype RecordId = Int let x: RecordId = 5let y = x + 10 extension

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

I think that tuples should remain what they are now. Static-length vectors should be types on their own and interact with tuples, with structs and with Array<…> in the same way. newtype should be what enables extension of tuples: newtype Money = (Int, Int) extension Money:

Re: [swift-evolution] [Discussion] Simplifying case syntax

Hi Erica, thanks for restarting the discussion—I hope that it will be considered on topic for stage 2. I agree that the part with preventing let .case(existingVar, newVar) should be moved out of the proposal, because these issues are orthogonal. So the options with ~= and := will differ only in

Re: [swift-evolution] 'T != Type' in where clause

But it already works without where T != Self. Moreover, I guess, this solution is currently considered “good enough” not to introduce additional complexity to type system. Also, on and and or—the former already exists in the form of &, and the latter is listed in commonly proposed rejected

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

+1 to foo(:) version. I can easily see placeholder arguments as a sugary syntax for closures: func bar(_ x: Int, _ y: Double) let f = bar(_, 42) // the same as: let f = { (x: Int) in bar(x, 42) } Now, let’s view a single-parameter version: func foo(_ x: Int) let f = foo(_) // the same as:

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 21:01 GMT+03:00 Matthew Johnson : > > I don’t understand what you mean here. > I was a bit confused. Thanks to your clarification, I discovered that `rethrows` functions currently can use `throw` expression, but only in `catch` scope, which handles error

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

When I started changing the proposal, I noticed that examples with throws(E) look uglier than with rethrows, because of required constraint of E: Error. So I’d like to also discuss removal of Error constraint and its consequences. Some people talked about Objective-C interop. What are those

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

2017-02-23 20:09 GMT+03:00 Matthew Johnson : > > On Feb 23, 2017, at 10:58 AM, Anton Zhilin wrote: > > See some inline response below. > Also, have you seen the issue I posted in Proposal thread? There is a way > to create an instance of "any"

Re: [swift-evolution] [Discussion] Analysis of the design of typed throws

See some inline response below. Also, have you seen the issue I posted in Proposal thread? There is a way to create an instance of "any" type. 2017-02-23 3:37 GMT+03:00 Matthew Johnson via swift-evolution < swift-evolution@swift.org>: > # Analysis of the design of typed throws > > ## Problem > >

Re: [swift-evolution] [Proposal] Typed throws

As a follow-up, here is code that you can test now. It demonstrates the same, but with normal function result. func createArbitrary(usingGenerator f: () -> (T)) -> T { let any: Any = 42 as Any if Int.self is T.Type { let t = any as! T return t } return f() }

Re: [swift-evolution] [Proposal] Typed throws

I understand how parametric polymorphism works *in Haskell*. But we talk about Swift, and there *is* a way to get an instance of E. I’ll explain it another way: func bypassRethrows(_ f: () throws(E) -> ()) throws(E) { let error: Error = MyError() // create an instance of `MyError` if

Re: [swift-evolution] [Proposal] Typed throws

2017 at 2:34 PM Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > >> Now that I think about it, generic throws does not exactly cover rethrows >> . >> Firstly, rethrows has semantic information that function itself does not >> throw—it wo

Re: [swift-evolution] [Proposal] Typed throws

2017-02-21 1:21 GMT+03:00 Matthew Johnson : > > Thanks for the links. I scanned through them somewhat quickly and didn’t > see anything that specifically said `Never` should conform to all > protocols. Did you see that specifically? I only saw mentions of it being > a

Re: [swift-evolution] [Proposal] Typed throws

I messed up with links a little bit, duplicating one of them. Here is another one. ​ ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Proposal] Typed throws

2017-02-20 18:23 GMT+03:00 Matthew Johnson : > On Feb 20, 2017, at 3:58 AM, Anton Zhilin wrote: > > But that raises another concern. In a previous discussion, it was taken > for granted that Never should conform to all protocols > > Do you have a

Re: [swift-evolution] [Proposal] Typed throws

2017-02-19 23:29 GMT+03:00 Matthew Johnson : Thanks. There is nothing wrong with this at all. Your second `exec` would > not accept a non-throwing function because `Never` cannot conform to > `Default`. If it didn’t include the `Default` constraint it would not be >

Re: [swift-evolution] [Proposal] Typed throws

2017-02-19 22:59 GMT+03:00 Matthew Johnson : On Feb 19, 2017, at 1:32 PM, Anton Zhilin wrote: > > Now that I think about it, generic throws does not exactly cover rethrows. > Firstly, rethrows has semantic information that function itself does not

Re: [swift-evolution] [Pitch] Typed throws

It’s expected that if you need resilience, then you will throw an “open” enum. Essentially, we pass resilience of typed throws on to those who will hopefully establish resilience of enums. If you prefer separate error types, then declare a base protocol for all your error types and throw a

Re: [swift-evolution] [Proposal] Typed throws

2017-02-19 0:16 GMT+03:00 Martin Waitz : > > Now some bike-shedding: > I’m not really happy with the `throws(Type)` syntax, as it is too close to > function parameters. > Why exactly is `throws Type` ambiguous? > The proposal mentions `Type -> Result` as potential thrown type,

Re: [swift-evolution] [Proposal] Typed throws

Now that I think about it, generic throws does not exactly cover rethrows. Firstly, rethrows has semantic information that function itself does not throw—it would be lost. Secondly, rethrows allows a function with multiple throwing function parameters to become non-throwing iff all the arguments

Re: [swift-evolution] [Pitch] Refactor Metatypes

Type is a bad name for a public type: FooType is almost always a better name. Libraries that describe “just types”, Swift types, can as well use Metatype or Mirror or something. For nested types, like Foo.Type, in the meaning of “type of Foo“, Type can’t be used even now. I’d give up on Type name

[swift-evolution] [Proposal] Typed throws

I’ve created a proposal draft, copy-pasting some parts from David Owens’ proposal. Here it is . I had to make one addition, which hasn’t been discussed yet. Look at Multiple throwing calls

Re: [swift-evolution] [Pitch] Typed throws

Several proposals will follow this one: allowing multiple error types, removing Error, replacing rethrows, etc. Those topics are more controversial, but fortunately for them, they mostly add on top of the core feature being discussed. So IMO, if a detail can be split into its own proposal, we

Re: [swift-evolution] [Pitch] Typed throws

In this case, you’d better create a new error type, which includes all the cases of those errors: // FileNotFoundError and WrongFormat are Error-s struct PreferencesError : Error { init(_: FileNotFoundError) init(_: WrongFormat) // ... } func readPreferences()

Re: [swift-evolution] [Pitch] Typed throws

2017-02-17 22:12 GMT+03:00 Adrian Zubarev via swift-evolution < swift-evolution@swift.org>: Is the throwing type always a protocol? In your example it is, but is this > going to be always the case? > I thought it was going to be any one subtype of Error, be it a struct, an enum, or a protocol

[swift-evolution] [Pitch] Typed throws

Now this is on-topic, I guess. Last time we stopped at John McCall’s syntax: extension MyError: Error { ... } func foo() throws(MyError) -> MyResult It’s conservative and prevents visual ambiguity with extra parentheses. If we (somewhat) agree on this, then submitting a proposal will be

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

Just let @pure func foo(_ f: (Int) -> Int) -> Int be the same as those two combined: @pure func foo(_ f: @pure (Int) -> Int) -> Int func foo(_ f: (Int) -> Int) -> Int No need for anything like “re-pure” or ≃>. ​ ___ swift-evolution mailing list

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

I didn’t mean to emphasize any specific syntax. I’m fine with either @const, @constexpr, @pure or =>. Anyway, I see no reason why generic functions shouldn’t be supported in any of the suggested models. 2017-02-17 19:08 GMT+03:00 Abe Schneider : +1. I think this is a

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

2017-02-17 17:13 GMT+03:00 T.J. Usiyan : It is my opinion that you are describing an entirely different, and > somewhat orthogonal, feature. I would like the feature that you describe. > Constant expressions are powerful and open up quite a few optimizations. > What

Re: [swift-evolution] [Pitch] Refactor Metatypes

I guess, now is the time? The response on this has been positive, both for the new metatype syntax and separation of static and dynamic metatypes. I’ve got one more feature in mind since then—a shorthand of AnyType ≡ AnyType. Would this addition be worth extra syntax? Is it feasible from current

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

My vision of “pure” functions was the following: 1. Compiler automatically marks all functions and expressions as pure, wherever possible - We should be interested not in “Haskell-ish pure” functions, but in “computable during compilation” functions - Therefore I prefer to

Re: [swift-evolution] array splatting for variadic parameters

2017-02-14 18:32 GMT+03:00 Dimitri Racordon via swift-evolution < swift-evolution@swift.org>: The proposal is indeed really interesting. > I would love to see if it could get a second round of discussion. > > However, I failed to understand the syntax of the proposed extension. > Where would be

Re: [swift-evolution] for in? optionalCollection {

for i in test ?? [] { print(i) } For a more general solution, we could add Optional.flatten() to support optional sequences: for i in test.flatten() { print(i) } ​ ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Overriding protocol default implementation

I’d even suggest to force final for such methods: protocol Fooable { } extension Fooable {// func foo() { }// error: must be declared as final final func foo() { } // ok } ​ ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] !? operator for ternary conditional unwrapping

With Runes , this looks like: (name1 <^> { "\"\($0)\"" }) ?? "null" Runes defines <^> to have lower precedence than ??. Sadly, they all can’t be in the same precedence group due to right associativity of ??. 2017-02-08 18:11 GMT+03:00 Tony Allevato via

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

2017-02-06 15:35 GMT+03:00 Tino Heth via swift-evolution < swift-evolution@swift.org>: > Consider even if we had compile-time constants like Vector — > how would that be implemented? What would its backing-type be? > > Imho it's very simple — UnsafeMutableBufferPointer would be an

Re: [swift-evolution] for-else syntax

You can write a helper method that adds a placeholder if the array is empty: for name in names.placeholder("no names") { print(name) } Implementation: extension Collection { func placeholder(_ elem: Iterator.Element) -> PlaceholderView { return

Re: [swift-evolution] Default Generic Arguments

Current alternative to default generic arguments is typealias, like basic_string and string in C++: struct BasicBigInt { ... } typealias BigInt = BasicBigInt It’s not *that* ugly. It keeps type inference rules simpler, easier to understand and more explicit. As someone noted, current type

Re: [swift-evolution] Testing enum cases with associated values

AFAICS, Andy needs not default implementations of Equatable, but cases-as-optional-properties—this topic has also been discussed on the list. enum Result { case success(Int) case failure(String) } let r: Result = foo() let x: Int? = r.success let y: String? = r.failure assert(r.success

Re: [swift-evolution] Will existentials ever conform to their protocols?

There is also a caveat with static members: protocol P { static func foo() } struct S : P { static func foo() { } } func bar(x: T) { T.foo() } let p = S() as P bar(p) // P.foo() does not exist ​ ___ swift-evolution mailing list

Re: [swift-evolution] Reduce with inout

While realizing that this name can cause confusion, I'd still prefer `reduce(mutating:_:)`, because it looks like the only readable option to me. Whatever name will be picked, I agree that traditional reduce without mutation should retain its name. 2017-01-18 5:17 GMT+03:00 Xiaodi Wu via

Re: [swift-evolution] Fixing raw enum types

2017-01-17 22:26 GMT+03:00 Joe Groff : > enum Something : RawRepresentable > +1. But we don’t have generic protocols right now :( > > I think this would be the right direction to go if we wanted to de-magic > the existing RawRepresentable behavior. At this point, It would be >

Re: [swift-evolution] Fixing raw enum types

Some criticism for all the mentioned variants: enum Something : raw(Int32) Requires adding a new contextual keyword. enum Something : RawRepresentable With additional typealias RawValue, the simplest cases will lose their elegancy. enum Something : RawRepresentable +1. But we don’t have generic

[swift-evolution] Fixing raw enum types

This idea by Karl made me branch off a new thread. 2017-01-16 21:28 GMT+03:00 Karl Wagner : It would be helpful for synthesised RawRep conformance. The > inheritance-like syntax we have now is awful - it makes people think that > RawRepresentable is some kind of magic

Re: [swift-evolution] protocol-oriented integers (take 2)

What about taking a mathematical approach to numbers? protocol Group : Equatable { static var zero: Self { get } static func + (Self, Self) -> Self static func += (inout Self, Self) static func - (Self, Self) -> Self static func -= (inout Self, Self) static prefix func -

Re: [swift-evolution] Generic Subscripts

I’m not sure, but I think that in this case the specific type of these values is determined at runtime. Then a safe approach would be separate string: String?, bool: Bool?, int: Int? computed properties, as it’s done in JSON parsers. if let bookCount = row.value(named: "bookCount").int { ...

Re: [swift-evolution] Equatability for enums with associated values

That seems pretty close to Rust’s derive. Why not invent a similar syntax in Swift? Otherwise it will make us look through all the sources to make sure deriving is used. enum Option: @derive Equatable { ... } Also, we can get better looking compilation errors, like: ERROR at line 1, col 14:

Re: [swift-evolution] Consolidate Code for Each Case in Enum

2017-01-12 0:51 GMT+03:00 David Sweeris : > > I don't understand the lines in the struct version where you assign > something to `self`. What is ".invalid", for example? I thought you'd > removed the enum altogether. > I totally overlooked it. That can't be done with

Re: [swift-evolution] Consolidate Code for Each Case in Enum

Wouldn’t protocols be a better solution in this case? If little to no logic can be shared between enum cases, why have the enum in the first place? Your variant: protocol State { mutating func react(to event: Event) } enum AuthenticationState: State, CustomStringConvertible { case

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

I also thought about sum types as implementation of errors, but selecting between Tyler’s and John’s syntaxes, I would pick the latter. Compare: let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double)) let x: (_ a: Int) throws(Error) -> (_ b: Float) throws(Error) -> Double let x: (_ a:

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1 to obtain, unwrap and such. +1 to removing optional pattern in favor of normal if-pattern, plus removing case: if let unwrapped? = optionalValue { ... } ​ ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

I have no problem with the syntax proposed in SE-0068. The rationale briefly mentions that dynamic Self will be used anywhere inside the class body. I think that the possibilities that open with this decision should be mentioned in the proposal. We can say that non-final classes, apart from that

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

What about “Rust way”? protocol Default { static var `default`: Self { get } } protocol Setupable { mutable func setup(with params: Params) } func setupArray(type: T.Type, params: Params) -> [T] where T: Default & Setupable { return (1...42).map { i in var next =

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

TLDR: I support moving throws, and also think that ‘typed throws’ should fit for Phase 2, at least. let x : (_ a : Int) -> (_ b: Float) throws -> Double throws Count me in those who cried in anger :) -- I see why current syntax is very logical for currying: let x:

[swift-evolution] Replace named returns with `out` parameters?

Some people on the list wondered, why we have moved from tuples in function parameters, but multiple returns are still implemented using tuples? The following code still compiles: func position() -> (x: Int, y: Int) { return (x: 0, y: 0) } let (y, x) = position() (Maybe it’s a bad example,

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

This proposal should be reviewed as a part of “typed throws” proposal, with the original PR prepared by David Owens. Typed throws won’t change anything about how many types can be thrown. Only one type/protocol will be specified in the function

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

2016-12-20 0:59 GMT+03:00 Derrick Ho : The core team designed swift blocks to range from concise to verbose. Which > one you use depends on your needs. > > If you want to write parenthesis then by all means write parenthesis; no > one is stopping you. > > I would rather keep

Re: [swift-evolution] Swift Closure still inconsistent -- tuple names need to be in curly brackets, single parameter needs to be in parentheses

2016-12-17 2:55 GMT+03:00 Vip Malixi via swift-evolution < swift-evolution@swift.org>: var oneParameterAndMultipleReturn: ([Int]) -> (even:[Int], odd:[Int]) = { > numbers -> ([Int], [Int]) in > var evenNumberArray = [Int]() > var oddNumberArray = [Int]() > > for number in numbers { >

Re: [swift-evolution] Pattern matching with Arrays

2016-12-19 3:09 GMT+03:00 Lucas Neiva via swift-evolution < swift-evolution@swift.org>: > case let [first, next...]: > > case let [first, last]: > > The binding should be more like "[let first, let last]" though, to be more > like the tuple matching. For the above also: "case [let head, let

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

It will be impossible without huge additional overhead. I assume that "invalidated" means "no more points to that element". Consider that an element is inserted in the middle of an Array. Assuming enough capacity, all iterators after that one will be invalidated. But all new iterators pointing to

Re: [swift-evolution] [Discussion] Generic protocols

2016-12-10 14:57 GMT+03:00 Adrian Zubarev : I’m fine with adding features step by step. ;) > > There is no need for an explicit type alias in your > > extension MyStruct : Constructible { … } > > Because Value is already constrained by String. > That was my

Re: [swift-evolution] [Discussion] Generic protocols

I have to agree with Tino Heth, our aim is to add something basic at first. Although we’d better make sure that we will be able to add other wanted features in the future. How about this plan? 1. Generic protocols without associated types 2. Basic conflict resolution using “dot” syntax

Re: [swift-evolution] [Discussion] Generic protocols

A fundamental problem is, how do we get rid of associatedtype duplicates? A pedantic approach is to add trait operations for conformances: protocol Constructible { associatedtype Value init(_ value: Value) } struct MyStruct { conformance Constructible { rename associatedtype

Re: [swift-evolution] [Discussion] Generic protocols

What makes me worry is if this syntax is really the best one possible: typealias ConstructibleFrom = ConstructibleFromValue where ValueType == V I find it strange that such exact line with typealias and where is required. I was hoping for an expression that lets us specialize a protocol and use

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

2016-12-02 3:55 GMT+03:00 Ramiro Feria Purón : > *Unlike C++'s templates, a Swift's generic function is semantically a > single function.* > > Anton, could you provide further insight on this? > Basically, generic functions in Swift are implemented as functions

Re: [swift-evolution] Proposal: Allow explicit type parameter specification in generic function call

I disagree with the suggestion. Unlike C++'s templates, a Swift's generic function is semantically a single function. One can say that together with a metatype parameter, we pass in witness table. What I think we should do is make metatypes easier to use. *Adrian and I have a PR* that has already

Re: [swift-evolution] Some concerns on custom operators

2016-11-28 5:09 GMT+03:00 Robert Widmann via swift-evolution < swift-evolution@swift.org>: > That is what was happening for me at the time. Operadics was exporting > bind (>>-), ap (<*>) and fmap (<^>), and SwiftCheck was pulling in > Operadics inline in the non-SPM build. The two modules were

Re: [swift-evolution] Symmetrical operators

-1 Not worth adding syntactic sugar for a narrow use case. Plus it's an additive feature. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Some concerns on custom operators

2016-11-09 22:20 GMT+03:00 John McCall <rjmcc...@apple.com>: > > On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > > • Upon implementation of SE-0077 in Swift 3, some libraries > started to drop operat

Re: [swift-evolution] Some concerns on custom operators

2016-11-09 21:56 GMT+03:00 Joe Groff : > > Do you know if bugs have been filed about these issues? IIRC, SE-0077 > specified that precedence groups should act like normal named declarations > and be scopable. The fact that they aren't sounds like a bug to be fixed. > I don't

[swift-evolution] Some concerns on custom operators

1. Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely: link #1 , link #2 . - Declarations of the same custom operator with different

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

2016-11-09 0:12 GMT+03:00 Adrian Zubarev : Could you elaborate an implementation for one of these functions: > func == (left: T?, right: Nil) { switch left { case .some(_): return false case .none: return true } } The implementation is

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

2016-11-09 0:11 GMT+03:00 arkadi daniyelian : I could not clearly see the exact, concrete problem with the current > implementation. IMAO such fundamental change requires a *very* serious > reason and some thought on performance side of thing. > Performance will not be hurt,

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

2016-11-08 23:44 GMT+03:00 Adrian Zubarev : At first glance this doesn’t make any sense to me: > > public protocol ExpressibleByNilLiteral { > associatedtype NilLiteralType = Nil > init(nilLiteral: NilLiteralType) > } > > What’s the need for associatedtype

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

2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez : Thank for thinking of this. I am not sure on the advantage of having nil as > a concrete type. > > Have you seen this talk? > > https://realm.io/news/swift-summit-al-skipp-monads/ > > "The concept of “nil” does not exist in

[swift-evolution] [Pitch] Nil struct

Gist link Introduction Change nil literal type from () to Nil. Before: public protocol ExpressibleByNilLiteral { init(nilLiteral: ()) } After: public struct Nil { init() } public protocol ExpressibleByNilLiteral {

Re: [swift-evolution] Postfix operators that start with ? or !

Hello Tony, Feel free to file a bug report. If there are no spaces between operator characters, then they should be parsed as a single operator. ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

I'd like to write a proposal for "matches" and wonder if it is in Swift 4 Phase 1 scope? It's purely syntactic, and won't affect ABI. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

infix operator ♠️ : LogicalDisjunctionPrecedenceinfix operator ♥ : LogicalDisjunctionPrecedence func ♠️(lhs: Bool, rhs: @autoclosure () throws -> T) rethrows -> T? { if lhs { return rhs() } else { return nil } }func ♥(lhs: T?, rhs: @autoclosure () throws -> T) rethrows -> T { return lhs ??

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Why can't we just remove distinction between operator and identifier symbols? I'd be fine with the following: ```swift infix operator map infix func map(lhs: [Int], rhs: (Int) -> Int) { ... } [1,2,3] map {$0*2} ``` No explicit imports required, plus we can create nice DSLs. Of course, it's an

Re: [swift-evolution] [Pitch] Reimagining guard case/if case

Haravikk, I fully agree with you; before I read your post I thought I’d write exactly that. if matches 1. Another “ideological” reason: = is just an operator, so lhs = rhs should be an expression, but meaning of = is overloaded in this context. On the other hand, when you see a keyword, you

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

I'd prefer to replace $ with # in closure parameters, plus make $ equal in rights to other currency symbols. In C and JS, dollar sign is actually equal in rights to other currency symbols. Swift is closer to them than to Perl, Shell, PHP, so it makes sense to follow them here.

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

Purely additive feature, not for Swift 4 Phase 1. And a -1 from me for reasons already mentioned. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Currently, we can expect that fields of a type are all collected in the same place. This expectation applies more for "static" and less for "dynamic" types. So I agree with the idea for @objc classes, strongly disagree for structs, and disagree for regular classes.

Re: [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

A quick fix: guard let value = dict["Key"].map({ $0 as NSString }) { use(value) } Current behavior is quite logical: main purpose of as? is to perform casts, which are not guaranteed to succeed. But I’d say that as? should also support what you want. ​

Re: [swift-evolution] private & fileprivate

As far as I can see, almost all people, who talk here, agree that private / fileprivate distinction brought more harm than good. Despite corresponding proposal being accepted. I think, it means that current mailing-list system is failing. Let's accept it, gmane looks and feels ugly by comparison

[swift-evolution] [Question] Types of functions

// Swift 2.2print([Int].append.dynamicType) //=> inout Array -> Int -> ()print(print.dynamicType) //=> (Array>, String, String) -> () // Swift 3print(type(of: [Int].append)) //=> (inout Array) -> (Int) -> ()print(type(of: print)) //=> ((Array, String, String)) -> () Question #1:

Re: [swift-evolution] [Pitch] Refactor Metatypes

2016-09-30 22:48 GMT+03:00 Xiaodi Wu via swift-evolution < swift-evolution@swift.org>: Sorry, my question at least has nothing to do with bikeshedding. I'm > confused about why the proposal feels it's necessary to have both Type and > Subtype. I don't understand Brent's two reasons and was hoping

Re: [swift-evolution] [Pitch] Refactor Metatypes

2016-09-29 3:31 GMT+03:00 Colin Barrett via swift-evolution < swift-evolution@swift.org>: >- > >Type is the concrete type of T.self. A Type only ever has one >instance, T.self; even if T has a subtype U, Type is not a subtype >of Type. >- > >Subtype is the supertype of

Re: [swift-evolution] [Proposal draft] Conditional conformances

I find the limitation of non-intersection of conditional conformance reqirements quite limiting. Can it be lifted in case there are no overloaded functions between extensions? protocol A { func foo() } protocol B { func bar() } extension Array: A where Element: A { func foo() { return

[swift-evolution] Source-breaking proposals?

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? ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] pattern matching on variable-sized data type

You can process lists using pattern matching today: enum List { case Nil indirect case Cons(T, List) } let list: List = .Cons(2, .Cons(3, .Nil)) switch list { case .Nil: ... case .Cons(let x, .Nil): ... case .Cons(let x, .Cons(let y, .Nil)): ... default:

Re: [swift-evolution] #pragma

AFAIK, if one would extend Swift beyond its "official" specification, it could be done using #-directives and @-attributes, like Swift playgrounds use #imageLiteral(...) and friends. It's somewhat equivalent to pragmas of C++. On the other hand, things that are not understood by target compiler,

Re: [swift-evolution] [Pitch]: Require parenthesis for ternary operator '?:' or change its priority

With the replacement, I would prefer just "then-else", which would still clearly carry the meaning of low priority. But yes, this option was explicitly rejected. Unfortunately. I also agree that changing the priority is not a solution. But how about removing priority? The following expression:

Re: [swift-evolution] Type-annotated throws

+1 for removing Error protocol. Then it's a breaking change, and this edition of the proposal can be reviewed for Stage 1. Swift error model tries to be different (better) than of other languages. We encourage not to rethrow, but to think of errors as of meaningful results and process them

Re: [swift-evolution] Type-annotated throws

Forwarding to more people: This idea has already been discussed, and Chris Lattner specifically mentioned that this proposal will be suitable for Swift 4 Phase 2. But right now we shouldn't create a proposal for this. ___ swift-evolution mailing list

Re: [swift-evolution] Type-annotated throws

Felix, this idea has already been discussed, and Chris Lattner specifically mentioned that it is planned for Swift 4 Phase 2. But right now we shouldn't create a proposal for this. ___ swift-evolution mailing list swift-evolution@swift.org

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

Syntax for `T == P || T: P` is off-topic for current proposal, which is just about replacing `P` with `Any`. Currently, equivalent of `Any` has no subtypes (besides itself). This is likely not going to be changed. So `where U : Any` will not be allowed. Generalized existentials also don't solve

  1   2   3   >