Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists. On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote: If we were really concerned about this, a narrower way to solve the same problem would be to allow a comma before

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I don't feel that InvariantSelf reflects the fact that class conformed to protocol with `f()->InvariantSelf` requirement will actually return 'self or some base class'. Especially when this `InvariantSelf` means `exactly this concrete static type name` inside type declaration. Probably the

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> canImport (or whatever it ends up being called) is deliberate. > > You test before you import: > > #if canImport(x) >import x > #else > ... > #endif > > and you test at the use-site > > #if canImport(x) > // use things that are available in x > #else > ... > > So you don't import

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Regards (From mobile) > On May 13, 2016, at 7:01 AM, Chris Lattner via swift-evolution > wrote: > > On May 12, 2016, at 4:50 PM, Joe Groff wrote: --- a.swift +++ a.swift foo( x: 0, - y: 1 + y:

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> Gwendal Roué wrote: > > `#if import Foo` can not deal with the fact that a single source file may > have to perform the importability test several times. This would be less of a problem if conditional imports like that worked locally in all scopes of code, so you could write just func

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Why did you decide to drop the `#` ? As `StaticSelf` will be resolved on compilation time like #file etc ? I feel like this is inconsistent solution. Also, do you expect this will work: protocol A { func g()->StaticSelf } class B: A { func g()->StaticSelf {return B()} } class C: B {

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

Hello, `#if import Foo` can not deal with the fact that a single source file may have to perform the importability test several times. For example: #if canImport(UIKit) import UIKit // Some UIKit-related declarations #endif // Later in

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> Le 13 mai 2016 à 11:05, Pyry Jahkola a écrit : > >> Gwendal Roué wrote: >> >> `#if import Foo` can not deal with the fact that a single source file may >> have to perform the importability test several times. > > This would be less of a problem if conditional imports

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

> On 10 May 2016, at 19:51, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? I’m a +1, however personally I’d prefer this to be optional my constraints aren’t that complex, for example: func

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

Patrick, I think you're making valuable points here. I also can't think of cases where you wouldn't also import a module in case it was found to be importable. So the use cases I can think of could as well be tackled by allowing expressions such as `import Foo.Bar` as compile-time checks

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Matthew Johnson via swift-evolution writes: > Consider the following example, under the current system: > protocol StringCreatable { > static func createWithString(s: String) -> Self > } > > extension NSURL: StringCreatable { > // cannot conform because NSURL is

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

I can’t decide if this would be a good idea or not? I can see pluses and minuses! + Consistent. One way to remember to work with modules. Reinforces the rule that if you want to work with a module, you want to import it. - Could get confusing exactly where things are being imported, but you

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Considering the precedent of using ! and ? in swift, could it be that: Self! would designate what is known for sure, the invariant compile time type of self Self? Would designate the yet unknown (*optional* if you will) covariant type of self Regards LM (From mobile) > On May 13, 2016, at

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

> I’m a +1, however personally I’d prefer this to be optional my constraints > aren’t that complex, for example: > > func someMethod(value:T) { … } > > Personally I prefer to keep such simple cases as they are, but would happily > use the new ability to move more complex ones (e.g-

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I would prefer BaseSelf. > On May 13, 2016, at 2:28 AM, Vladimir.S via swift-evolution > wrote: > > via ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

On 13.05.2016 9:45, Patrick Smith wrote: Could protocol Self change to just the first behaviour for classes? If a conformance absolutely needs to have a method returning ‘only me but not my subclasses’, then it sets that conforming method to be final. Hm.. Do we *need* to change `->Self`

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

Well my idea also included module(X), modelled after the os() function, e.g. #if os(OSX) #if import UIKit // Some UIKit-related declarations #endif // Later in the same file func f() { #if module(UIKit) // Use UIKit-only declarations #endif } Looking

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> I'm not convinced by this example. Probably my & Matthew's previous discussion in `[swift-evolution] [RFC] #Self` topic will help you. I was trying there to find out (in primitive examples) what Matthew is trying to achive with this `->StaticSelf` in protocol. In two words - he wants to

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

The other advantage of Self! over StaticSelf is that in code completion, Self, Self? Self! Will come together, giving people a quick tool to discover/remind themselves of the semantic difference right at the point of use. It might also address Joe's comment about StaticSelf not being much of

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

I don't understand. Right now we are allowed to have Optional(Self) : protocol A { func g()->Self? } class B: A { func g()->Self? {return self} } print(B().g()) //Optional(main.B) How do you want to divide your `->Self?` and this currently possible `->Self?` ? But I do like the idea

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On 13 May 2016, at 07:22, Vladimir.S via swift-evolution > wrote: > > It seems like all problems could be solved by allowing line-break instead of > comma in list: For what it's worth, I'm very much in favour of this idea of allowing line breaks instead of

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

That makes sense to me. > On May 13, 2016, at 2:45 AM, Patrick Smith via swift-evolution > wrote: > > If a conformance absolutely needs to have a method returning ‘only me but not > my subclasses’, then it sets that conforming method to be final.

Re: [swift-evolution] Optional assignment operator

Yeah, as previously discussed you’d usually be better doing something like: struct Foo { var value:Int? func someMethod() { let value = self.value ?? 0 // This is no longer optional … }

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Could protocol Self change to just the first behaviour for classes? If a conformance absolutely needs to have a method returning ‘only me but not my subclasses’, then it sets that conforming method to be final. > On 13 May 2016, at 4:38 PM, Vladimir.S wrote: > > The

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

Awesome! :) You are too fast to follow up! - Dennis Sent from my iPhone > On May 13, 2016, at 7:02 AM, Chris Lattner wrote: > > On May 12, 2016, at 12:59 AM, Dennis Weissmann via swift-evolution > wrote: let item = DispatchWorkItem(qos:

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Totally agree. It feels weird to have protocols decide on how "Self" conformance a are inherited. It should a decision for the conforming type. > On 13 May 2016, at 04:21, Joe Groff via swift-evolution > wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

How about BaseType? (as just `Type` can not be used here) Or ThisType? And, do you think we actually should use `#` here in analogue to #file as this `StaticSelf` will be pre-processed on compilation stage to be replaced with actual type name? On 13.05.2016 5:21, Joe Groff via

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

It seems like all problems could be solved by allowing line-break instead of comma in list: public init(source: JSONObjectDecoder) throws { try self.init( imageSource: source.decode("imageSource") width:

[swift-evolution] [Pitch] Add toplevel keyword for protocols

For some protocols we'd like to require top-level (free) functions, e.g. for many math functions such as abs() or sin(). We already do this implicitly for operators. *Proposal* Allow top-level function/property requirements in protocols, e.g.: public protocol AbsoluteValuable : SignedNumber {

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

In this case I propose to call it BaseType (or BaseSelf) as actually this 'thing' in meaning `->StaticSelf` means 'self or any base class' On 13.05.2016 7:56, Thorsten Seitz via swift-evolution wrote: +1 Good description of the motivating problem! As for bikeshedding: ConformingSelf,

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> The review of "SE-0075: Adding a Build Configuration Import Test" begins now > and runs through May 16. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md > > * What is your evaluation of the proposal? +1, I

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I do it quite a lot, especially for initialising structs, enums. I use it to get the same benefits as a switch statement spread over several lines. I think it’s often good to liberally apply new lines, as it aids legibility. Here some sample code of mine using it: extension ImageGraphic :

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I forgot to add I like this style particularly as it matches how the type is declared (below). There’s a symmetry between them all. Obviously each var in a struct doesn’t need a comma between it, so it would be nice to not have to type them in the other cases too! public struct ImageGraphic :

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On May 13, 2016, at 7:58 AM, Gwendal Roué via swift-evolution > wrote: > > >> Le 13 mai 2016 à 07:01, Chris Lattner via swift-evolution >> a écrit : >> >> On May 12, 2016, at 4:50 PM, Joe Groff wrote: >---

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Joe Groff wrote: >> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> * Operations that depend on sorted-ness and use binary predicates should >>> not be available on all Collections; they're too easy to misuse,

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution wrote: > On May 12, 2016, at 4:50 PM, Joe Groff wrote: >>> You’re arguing that you want to read Swift code written like this? >> >> I wouldn't mind it. > > I personally find that style

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

> On May 13, 2016, at 1:42 AM, Patrick Smith wrote: > >> canImport (or whatever it ends up being called) is deliberate. >> >> You test before you import: >> >> #if canImport(x) >> import x >> #else >> ... >> #endif >> >> and you test at the use-site >> >> #if

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Alright, so as you are also okay with `clamping` I will update the proposal with it. :-) - Luis On Fri, May 13, 2016 at 3:00 PM, Vladimir.S wrote: > Personally I don't feel like `flat` is better. Especially if there is > `clamping` in Range for the same purpose. Then we

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Sent from my iPad > On May 13, 2016, at 1:07 AM, Patrick Smith via swift-evolution > wrote: > > I do it quite a lot, especially for initialising structs, enums. I use it to > get the same benefits as a switch statement spread over several lines. > > I think it’s

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:26 PM, Vladimir.S wrote: > > I don't understand. > Right now we are allowed to have Optional(Self) : > > protocol A { > func g()->Self? > } > > class B: A { > func g()->Self? {return self} > } > > print(B().g()) //Optional(main.B) > > How do you

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Comments inline. Am 13. Mai 2016 um 09:31 schrieb "Vladimir.S via swift-evolution" : I don't feel that InvariantSelf reflects the fact that class conformed to protocol with `f()->InvariantSelf` requirement will actually return 'self or some base class'. Especially

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

I think there would be a certain elegance to allowing Boolean type expressions wherever types are currently allowed, so `A & B` being a replacement for `protocol` might look nice, and then extend that to allow concrete types as well. Then, if Swift ever decided to support union types, the

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that. I am also +1 on the current proposal because it exists and will be pretty useful in some cases and I can't predict how long it might be until such a new line proposal would be approved. I also think

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 13, 2016, at 8:37 AM, Thorsten Seitz via swift-evolution > wrote: > > Comments inline. > >> Am 13. Mai 2016 um 09:31 schrieb "Vladimir.S via swift-evolution" >> : >> >> I don't feel that InvariantSelf

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Am 13. Mai 2016 um 09:36 schrieb "Vladimir.S via swift-evolution" : Why did you decide to drop the `#` ? As `StaticSelf` will be resolved on compilation time like #file etc ? I feel like this is inconsistent solution. # is not needed just like it is not needed for

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

Personally I don't feel like `flat` is better. Especially if there is `clamping` in Range for the same purpose. Then we should not re-invent the wheel. On 13.05.2016 16:09, Luis Henrique B. Sousa wrote: Perhaps another word that could fit in the first case (truncate/bounded/within/clamping)

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

on Mon May 09 2016, Matthew Johnson wrote: > My claim is that substituting the constraint of “it has value > semantics,” while presumably looser than the PureValue constraint, would > not compromise the correctness of your view controller, so not only is > the meaning of

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

On 13.05.2016 16:32, Matthew Johnson wrote: I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that. Unfortunately I have no ability for this right now, so someone who is interested in this could take the idea and create a 'formal' proposal. I am also

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

on Mon May 09 2016, Matthew Johnson wrote: > Remember that the only value semantic reference types are immutable, so > the struct rendition of such types has only immutable properties. > Personally, I don't think that transforming > >struct X { > ... >

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

After all these discussions, and after I found out *for myself* what does the proposed `->StaticSelf` in protocol mean, I'm giving my strong +1 to this proposal. This will be a good and useful in some cases language feature, that will add flexibility to Swift. Also it will help to make the

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Brent Royal-Gordon wrote: >> * Operations that depend on sorted-ness and use binary predicates should >> not be available on all Collections; they're too easy to misuse, >> they're hard to name well, and as Nicola Salmoria has noted, they >> would not make any sense at

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Sent from my iPad > On May 13, 2016, at 9:19 AM, Vladimir.S wrote: > >> On 13.05.2016 16:32, Matthew Johnson wrote: >> I am, +1 on allowing new lines instead of commas. I suggest you pursue a >> proposal on that. > > Unfortunately I have no ability for this right now, so

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

on Mon May 09 2016, Nate Cook wrote: > Yet another alternative would be to drop Set and Dictionary down a > level to a FiniteSequence protocol in between Sequence and > Collection. Basically none of the index-based collection APIs > (i.e. everything except `count` and `isEmpty`) make sense on

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

Sent from my iPad > On May 13, 2016, at 9:19 AM, Dave Abrahams wrote: > > >> on Mon May 09 2016, Matthew Johnson wrote: >> >>Remember that the only value semantic reference types are immutable, so >>the struct rendition of such types has only immutable

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

It seems that there is a consensus that this proposal might be a good addition to the standard library. All comments on this thread in the past few weeks were related to naming, not around the behaviour or validity of the proposed methods. So I will submit this proposal for review very soon

[swift-evolution] Fwd: [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Resending message to list. Seems like iOS Mail (or me) really has problems with setting the reply to the list automatically :-( Thanks, Adrian, for notifying me. -Thorsten Anfang der weitergeleiteten E‑Mail: > Von: Adrian Zubarev > Datum: 13. Mai 2016 um

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 10:55 AM, Joe Groff wrote: > > >> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >> >> When I write a class Base with non-final methods that return instances of >> Base I can choose whether to state the return type as Self

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 10:39 AM, Joe Groff wrote: > >> >> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >> On May 12, 2016, at 9:21 PM, Joe Groff wrote: >> >>> On May 12, 2016, at

[swift-evolution] Removing "_ in" from empty closures

Currently if a closure takes a value, it requires "_ in" to note that the value is ignored. This makes sense in many cases, but creates a bit of a mess in the case of an empty, void-returning closure: doThing(withCompletion: { _ in }) I'd like to suggest that the compiler promote the empty

Re: [swift-evolution] Removing "_ in" from empty closures

Sent from my iPad > On May 13, 2016, at 11:16 AM, Joe Groff via swift-evolution > wrote: > > >> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution >> wrote: >> >> Currently if a closure takes a value, it requires "_ in" to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

While the community feedback on our SE-0041 proposal "Updating Protocol Naming Conventions for Conversions" (https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md) has been positive about the need to establish conventions, feedback has been

Re: [swift-evolution] Removing "_ in" from empty closures

+1. I've built APIs before where I wanted a method to take a closure that had multiple arguments, but where I would also like the client to be able to ignore the extra arguments if they didn't need that level of detail, and it would be nice to not require them to acknowledge those extra parameters

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On May 13, 2016, at 4:04 PM, Erica Sadun via swift-evolution > wrote: > >> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution >> wrote: >> On May 12, 2016, at 4:50 PM, Joe Groff wrote: You’re arguing

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Sent from my iPad > On May 13, 2016, at 9:21 AM, Tony Allevato via swift-evolution > wrote: > > I think there would be a certain elegance to allowing Boolean type > expressions wherever types are currently allowed, so `A & B` being a > replacement for

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 12, 2016, at 9:21 PM, Joe Groff wrote: > > >> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution >> wrote: >> >> The invariant StaticSelf identifier will always refer to A, unlike Self, >> which is

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:26 AM, David Hart wrote: > > Totally agree. It feels weird to have protocols decide on how "Self" > conformance a are inherited. It should a decision for the conforming type. Do you have any suggestions on how we allow the conforming type to make

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 12, 2016, at 9:21 PM, Joe Groff wrote: > >> >>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

What is your evaluation of the proposal? This is a welcome change, which also should open the door to rethink the ObjC `AnyObject` protocol and its confusing .Type `AnyClass`. Is the problem being addressed significant enough to warrant a change to Swift? Without a doubt. It feels way better

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

Sent from my iPad > On May 13, 2016, at 9:12 AM, Dave Abrahams wrote: > > >> on Mon May 09 2016, Matthew Johnson wrote: >> >>My claim is that substituting the constraint of “it has value >>semantics,” while presumably looser than the PureValue constraint, would

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

Sent from my iPad > On May 13, 2016, at 11:08 AM, Joe Groff wrote: > > >> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >> >> On May 13, 2016, at 10:39 AM, Joe Groff wrote: On May 13, 2016, at 8:18

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

> * What is your evaluation of the proposal? +1 conceptually, some quibbles. I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate. I understand

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Lets sum things up before I try to write a draft proposal for this feature `type<>` aka `all<>`. Is this feature out of scope for Swift 3? From my point of view it’s definitely not.  Is the name `type<>` really that bad for the compiler? Here I’m not sure, because that is out of my

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> On May 13, 2016, at 7:30 AM, Dave Abrahams wrote: > > > on Mon May 09 2016, Joe Groff wrote: > >>> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> * Operations that depend on sorted-ness and use

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 13, 2016, at 10:33 AM, Adrian Zubarev via swift-evolution > wrote: > >> >> But maybe we should consider generalizing this to type operators. The '?' >> For optional could then be a postfix type operator. And we could define our >> own type operators for

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >> wrote: >> >> on Mon May 09 2016, Nate Cook wrote: >> >> Yet another alternative would be to drop Set and Dictionary down a >> level to a FiniteSequence protocol in between Sequence and >>

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution > wrote: > > Currently if a closure takes a value, it requires "_ in" to note that the > value is ignored. This makes sense in many cases, but creates a bit of a mess > in the case of an empty,

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 1:45 AM, Patrick Smith via swift-evolution > wrote: > > Could protocol Self change to just the first behaviour for classes? > > If a conformance absolutely needs to have a method returning ‘only me but not > my subclasses’, then it sets that

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

IMO it will be nice to have ability to write: func f(obj: A) {..} if obj is A {...} obj2 = obj as! A (but I still don't understand real use case of things like (String | Int)) Btw, as we have `protocol` keyword for this feature to couple protocols, why we can't have `class` keyword to merge

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: > > >> On May 13, 2016, at 10:39 AM, Joe Groff wrote: >> >>> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson wrote: >>> >>> >>> >>> Sent from my iPad >>> >>> On May

Re: [swift-evolution] multi-line string literals.

That's my point. You start with a little two-line string and when you see you have those all over your code. A feature is never bad but a feature that may be misused creates temptation to go for bad programming practices, like "I'm using it just this once" and once you're there you never stop.

Re: [swift-evolution] [Pitch] Add toplevel keyword for protocols

To me this makes more sense for operators than for other functions or properties. For the former you could create conflict with previously declared function (or properties with variables) and there is no restriction in Swift that says you cannot or should not create a top level function or

Re: [swift-evolution] Removing "_ in" from empty closures

+1 here and I don't think it will make life more difficult for the compiler as it already handles the examples Joe Groff provided. On the contrary, by removing the need for those "_ in" declarations and checks you make the life of the compiler easier. - Leonardo On 13 May 2016 at 13:25, Matthew

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

As Thorstan forgot to resend his message to the list, here it is (read below). It should make things about `any<>` more clear. ——— func f(obj: class) {..} if obj is class {..} obj2 = obj as! class   and yes, probably

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 9:22 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 13, 2016, at 11:08 AM, Joe Groff wrote: >> >> >>> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >>> >>> > On May 13,

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On May 13, 2016, at 7:32 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 13, 2016, at 9:19 AM, Vladimir.S wrote: >> >>> On 13.05.2016 16:32, Matthew Johnson wrote: >>> I am, +1 on allowing new lines

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

'struct<>' does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol<> already covers this. I think this is not correct. Lets check this example: func foo(value: SomeProtocol) {     if let a = value as? struct {

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

> On May 13, 2016, at 7:04 AM, Erica Sadun wrote: > > On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution > wrote: >> On May 12, 2016, at 4:50 PM, Joe Groff wrote: You’re arguing that you want to read Swift

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Support. *all or nothing* :-) On 13.05.2016 20:29, Joe Groff via swift-evolution wrote: I don't see why we need to micromanage the situations where trailing commas are allowed. That's just unnecessarily increasing the fractal complexity of the language. We've delegated other style choices

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

Btw, if we'd have separate class<> and struct<> - we'd be able to have method to separate reference type from value type. We can write now : print(c is protocol<>) and we'd can: print(c is class<>) print(c is struct<>) Just thoughts.. On 13.05.2016 20:04, Vladimir.S wrote: On 13.05.2016

Re: [swift-evolution] Removing "_ in" from empty closures

Sent from my iPhone > On May 13, 2016, at 3:16 PM, Joe Groff wrote: > > >> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution >> wrote: >> >> Is anyone planning to write a proposal for this? > > Sounds like you just signed up!

Re: [swift-evolution] Removing "_ in" from empty closures

> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution > wrote: > > Is anyone planning to write a proposal for this? Sounds like you just signed up! -Joe > Sent from my iPhone > > On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution >

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

Having used, more or less continuously for my 20 years as a professional programmer, both a language that allows trailing commas and one that does not, I come down pretty strongly on the side of allowing trailing commas (for all the reasons already stated in this thread). If it means requiring a

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

This is certainly a detailed and well-considered proposal. I don't think the struct functionality makes much sense. There are two ways you can use the struct<...> construct: 1. struct. In this case the struct<...> representation is unnecessary; the

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

> * What is your evaluation of the proposal? -1 No one has been able to explain how this change improves readability, it just seems like it’s supposed to be self evident. I would argue that it makes the generic definitions less readable by separating declarations and their relevant where

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

Would there be any issue with the return type being AnySequence? It’s used in other areas: LazySequence & FlattenSequence’s dropFirst(n: Int) -> AnySequence dropLast(n: Int) -> AnySequence No need to introduce another type, and it’s straight forward to implement with AnySequence. > On 14 May

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Charles: I appreciate the attempt to minimize a current pain point and I agree on most of your analysis of the current NSError bridging but I think your proposal is fundamentally flawed. By forcing the core error type to have properties from NSError, you’re essentially finalizing what

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

If anyone is interested, I started a draft proposal with detailed design here:  https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-merging-types-with-protocols.md I didn’t post it here, because it is a bit huge and could lose its markdown formats. `all<>` is always bold,

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

> On May 13, 2016, at 9:29 AM, plx via swift-evolution > wrote: > > >> * What is your evaluation of the proposal? > > +1 conceptually, some quibbles. > > I agree with a few others that `synchronously` and `asynchronously` aren’t > ideal;

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

> On May 13, 2016, at 3:12 PM, Joe Groff wrote: > >> >> On May 13, 2016, at 9:06 AM, Matthew Johnson wrote: >> >> >>> On May 13, 2016, at 10:55 AM, Joe Groff wrote: >>> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

You asked for any example, I give it to you ;-) (as I said, it is syntactical, just to show that such struct<> can be used to test some struct for conforming to protocol, that was not conformed at writing time) Probably we can invent useful examples for this struct<> - but I don't believe it

  1   2   >