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

>* What is your evaluation of the proposal? +1. Having consistent conventions makes sense to me. I’d prefer `Initializable` to `Creatable` which sounds weird to me, but otherwise sounds great. >* Is the problem being addressed significant enough to warrant a change to >Swift? I think semantic

Re: [swift-evolution] Could enums have their rawValue type inferred?

> automatically cast rawValue when assigning an enum value to a variable or argument of the type of the enum's raw value That's exactly what I'm thinking, Leonardo. I was a little bit trying to avoid specifics because I don't understand the differences between autocasting and inference. There's

Re: [swift-evolution] Idea: Named extensions

Why not just use a (documentation) comment? /// The Lifecycle extension: extension ViewController { ... -Michael > Am 16.05.2016 um 18:26 schrieb Brandon Knope via swift-evolution > : > > I like to separate methods into their own logical extensions so similar >

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

> On May 15, 2016, at 1:48 PM, Dave Abrahams wrote: > > > on Mon May 09 2016, Matthew Johnson > wrote: > >>> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: >>> >>> >>> on Sat May 07 2016, Andrew Trick wrote:

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

> On May 16, 2016, at 1:38 AM, Tyler Fleming Cloutier via swift-evolution > wrote: > >> >> On May 15, 2016, at 11:17 PM, Tyler Fleming Cloutier via swift-evolution >> > wrote: >> >>> >>> On May 15,

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

> On May 16, 2016, at 1:39 AM, Dave Abrahams wrote: > > > on Sun May 15 2016, Tyler Fleming Cloutier > wrote: > >>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >>on Mon

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

> On May 16, 2016, at 10:14 AM, Dave Abrahams wrote: > > > on Mon May 16 2016, Matthew Johnson wrote: > >>> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: >>> >>> >>> on Fri May 13 2016, Matthew Johnson >> >

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

> On May 15, 2016, at 2:01 PM, Dave Abrahams wrote: > > > on Fri May 13 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 13, 2016, at 9:12 AM, Dave Abrahams wrote: >>> >>> on Mon May 09

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

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

Re: [swift-evolution] Union instead of Optional

Unlike sum types, such as Swift enums, unions don't have parametricity, because (T \union Nil) \union Nil == T \union Nil. This means that things like collections containing Optionals don't just work, since it becomes impossible for operations like 'find' to distinguish 'nil' as a value in the

Re: [swift-evolution] Union instead of Optional

> Am 16.05.2016 um 17:29 schrieb Michael Peternell via swift-evolution > : > > >> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution >> : >> >> Precisely. To me unions are to enums with associated type the same way >> tuples

[swift-evolution] [Proposal] New mechanism to combine Types with/or Protocols

I open a new thread just for clarity. This proposal was started two weeks ago in a discussion thread where I talked to the community and refined the proposal over a few past days. The overall response was positive to this proposal. Original thread: [Pitch] merge types and protocols back

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

On 16.05.2016 18:06, Patrick Smith via swift-evolution wrote: let foo: [Double] = Double[int32, int8, double, cgfloat, float] // As if you had written Double(…) around each item I really like this suggestion. Actually IMO we don't need explicit type declaration here: // clearly it is an

[swift-evolution] Idea: Named extensions

I like to separate methods into their own logical extensions so similar methods are grouped together. I do this mostly with Cocoa Touch where I like all view life cycle methods to be in the same extension: extension ViewController { override func viewDidLoad() { } override func

[swift-evolution] [META] Using escapes in Swift Evolution Proposal discussion links

The standard Swift Evolution proposal template includes the following introduction section: ## Introduction A short description of what the feature is. Try to keep it to a single-paragraph "elevator pitch" so the reader

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

> On May 16, 2016, at 9:29 AM, David Sweeris wrote: > > >> On May 16, 2016, at 10:18 AM, Chris Lattner via swift-evolution >> wrote: >> >> That said, it is also clear at this point that some of the loftier goals >> that we started out with

[swift-evolution] [RFD] Non-Self Protocol Requirements

The following situation has come up for me now and then: I want to work with groups of types that share a common behavior, but that behavior is not sourced in the implementation of the Self type but rather in a secondary type. Specifically, could Swift be extended to introduce a protocol

Re: [swift-evolution] [RFD] Non-Self Protocol Requirements

Yes, something like this would be handy! Even the ability to coerce from one type to another, if that destination type has a keyless initialiser for the source type. Here’s some imaginary syntax for with Erica’s array example. I would prefer a way to not have a separate type for ‘DoubleSource’

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

hi there, just skimmed through the bigger part of this thread — it's a really interesting discussion, but wouldn't it be worth a topic on its own? The title of this message addresses a much simpler question (that imho still deserves some answers ;-) Tino

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

On Tue, May 10, 2016 at 11:48 AM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0041: Updating Protocol Naming Conventions for > Conversions" begins now and runs through May 16. The proposal is available > here: > > >

Re: [swift-evolution] [Proposal/Pitch] Function decorators

> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution > wrote: > > >> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution >> > wrote: >> >> Hi swift-evolution, >> >> I want to

Re: [swift-evolution] [Proposal/Pitch] Function decorators

> On 16 May 2016, at 16:25, Erica Sadun wrote: > >> On May 8, 2016, at 10:33 AM, Karl Wagner via swift-evolution >> > wrote: >> >> >>> On 4 May 2016, at 00:46, Aleksandar Petrovic via swift-evolution >>>

Re: [swift-evolution] [Proposal/Pitch] Function decorators

Well, yes and no. A decorator receives a method and returns a new method, and it's up to implementation what will happen in the new method - it can perform some operations before calling the original method, or doing something after the original method is called, or not calling the original

[swift-evolution] Winding down the Swift 3 release

Hi Everyone, As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up to be. Ted posted details of the Swift 3 release process last week (https://swift.org/blog/swift-3-0-release-process/) and I just updated the

Re: [swift-evolution] Union instead of Optional

I don't really get it why the compiler is to complain about the if block not having an else in this case. That seems like a bug that will push us to write unnecessary code. The compiler is not capable of inferring there are more conditions to evaluate in an if statement opposed to a switch

Re: [swift-evolution] Union instead of Optional

> Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution > : > > Precisely. To me unions are to enums with associated type the same way tuples > are to structs. One is named, has well-defined semantics, can conform to > protocols, can have complex internal

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

At what point would you consider the Linux product to be viable for production server side application development. Do you think that goal has been achieved in swift 3.0. Or is it going to have to wait for the ABI lock down. I'm weighting the wisdom of possibly using Swift on linux for

Re: [swift-evolution] Idea: Named extensions

> On May 16, 2016, at 1:59 PM, Brandon Knope wrote: > > Do you have a link to your proposal? The part relevant to this thread is in the section “Interactions with other features”

Re: [swift-evolution] Idea: Named extensions

Because to me this seems too indirect and not explicit enough. I think doing it explicitly: • Makes your intent much clearer • Forces you to think about not throwing everything into one big extension (i.e. somewhat more binding than a comment that can easily be looked over) • Shows that it’s a

Re: [swift-evolution] Idea: Named extensions

Most of the Swift docs markup tech is both very new and still evolving. I'm trying to evangelize the technology, and there are now five markup items that actually tie into the code completion engine: Three new doc comment fields, namely - keyword:, - recommended: and - recommendedover:, allow

Re: [swift-evolution] Idea: Named extensions

I have never seen anyone use this. Why? Because it is relatively unknown and not very “pretty” in my opinion. In the ideal world, everyone would have perfectly formatted and up to date comment, but I am not convinced this is usually the case. It’s good for IDE documenting, but: • Online

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

> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution > : > >> I think an important point is that `all<>` should NOT be restricted to >> having only one reference or value type! > > This is a little problematic and I’m not a compiler expert so from my

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

With the generics and ABI stability goals getting pushed out to a future release, how does that affect the plans for Swift concurrency features? Will the topic still be explored in the Swift 4 timeframe, or do you expect that discussion be deferred to 5 or beyond? Dan > On May 16, 2016, at

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

Quite sad we could not get into ABI stability for Swift 3... but are we talking Swift 3.1 or 4.0? Sent from my iPhone > On 16 May 2016, at 17:43, Chris Lattner via swift-evolution > wrote: > > >> On May 16, 2016, at 9:29 AM, David Sweeris

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

> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution > : > >> internal func _arrayOutOfPlaceReplace >> >> (_ source: inout B, _ bounds: Range, _ newValues: C, _ insertCount: Int) >> where >> C.Iterator.Element == B.Element, >> B.Index == Int >> { >> >> Now only

Re: [swift-evolution] [Review] SE-0085: Package Manager Command Names

Hello Swift community, The Swift package manager core team met last week to discuss this proposal, and we ultimately *accepted* it relatively unchanged. I have amended the proposal to include more information on the alternatives discussed:

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

On May 16, 2016, at 10:38 AM, Goffredo Marocchi wrote: > Quite sad we could not get into ABI stability for Swift 3... but are we > talking Swift 3.1 or 4.0? We’ll start discussing post-3.0 releases in August. Until Swift 3 is really wound down, it is almost impossible to

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

On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution wrote: > Hi Everyone, > > As we get deeper into the Swift 3 release cycle, we’re beginning to have > a more precise understanding about what the release will shape up to be. > Ted posted details of the Swift 3 release process

Re: [swift-evolution] Idea: Named extensions

Sent from my iPad > On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution > wrote: > > Why not just use a (documentation) comment? > > /// The Lifecycle extension: > extension ViewController { There have been discussions about possibly allowing

Re: [swift-evolution] Idea: Named extensions

Do you have a link to your proposal? Thanks, Brandon > On May 16, 2016, at 2:58 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 16, 2016, at 12:33 PM, Michael Peternell via swift-evolution >>

Re: [swift-evolution] Idea: Named extensions

Or better yet, the 'Keyword" token offers searchable content that can relate one extension to the other. /// - Keyword: Lifecycle extension -- Erica > On May 16, 2016, at 11:33 AM, Michael Peternell via swift-evolution > wrote: > > Why not just use a

Re: [swift-evolution] Idea: Named extensions

I think requiring them to be in comments is what’s going to prevent their adoption. My fundamental stance is that these awesome features that are required in comments will be overlooked by people because: • You have to remember the specific syntax • There is no code completion which means you

Re: [swift-evolution] Idea: Named extensions

I have wanted this feature and floated it a while back. I hope we can get some traction this time but I doubt it will happen soon since additive features are tabled for a time. On Mon, May 16, 2016 at 3:47 PM, Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > I think

Re: [swift-evolution] Idea: Named extensions

Ya I didn’t see that email until after I wrote it up. If it does gain traction, I wouldn’t mind writing a proposal and tabling it for now. Would just like to see some discussion on it, but I don’t want to detract from the current goals! Brandon > On May 16, 2016, at 4:25 PM, T.J. Usiyan

[swift-evolution] [Accepted] SE-0092: Typealiases in protocols and protocol extensions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md The new proposal for SE-0092 "Typealiases in protocols and protocol extensions” is proactively approved for Swift. The core team consider this as an obvious follow-on to SE-0011, and

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

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

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

> On May 16, 2016, at 11:33 AM, Tim Hawkins wrote: > > At what point would you consider the Linux product to be viable for > production server side application development. Do you think that goal has > been achieved in swift 3.0. Or is it going to have to wait for the

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

> On May 16, 2016, at 2:06 PM, Joe Groff via swift-evolution > wrote: > > Looking to the future, many people have also expressed interest in the > ability to do dynamic type checks against metatype values, not only static > types, as in: +1 -- I’ve definitely

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

Currently, we parse a type after 'as[?!]' and 'is'. This is mostly what you'd expect, but does lead to problems when an 'as' expression appears as part of a comparison: 20 as Int64 < y as Int64 // error, '>' expected to close generic parameter list Int64 Looking to the future, many

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

> On May 16, 2016, at 11:53 AM, Ryan Lovelett > wrote: > > On Mon, May 16, 2016, at 11:18 AM, Chris Lattner via swift-evolution > wrote: >> Hi Everyone, >> >> As we get deeper into the Swift 3 release cycle, we’re beginning to have >> a more precise understanding

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

On May 16, 2016, at 12:29 PM, Dan Stenmark wrote: > With the generics and ABI stability goals getting pushed out to a future > release, how does that affect the plans for Swift concurrency features? Will > the topic still be explored in the Swift 4 timeframe, or do

Re: [swift-evolution] Idea: Named extensions

Here is an attempt to express myself better :) Objective-C to Swift category to extension conversion loss of descriptive name Objective-C category: @interface NSAttributedString (NSAttributedStringDocumentFormats) // Methods initializing the receiver contents with an external document data.

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

> I'm not an expert in the Linux communities needs and desires. That said, > from what I understand, they don’t care at all about ABI stability, since > everything is typically built from source. > > -Chris > > Not exactly true. (I care.) Video games (e.g. Steam/Linux) care deeply about ABI

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

On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution wrote: >> I'm not an expert in the Linux communities needs and desires. That said, >> from what I understand, they don’t care at all about ABI stability, since >> everything is typically built from source. >

Re: [swift-evolution] [Proposal] Remove behavior on AnyObject that allows any obj-c method to be called on it

I just saw these replies while searching for this thread, as I've been thinking of this proposal again recently. Regarding the API you point out, would it not be more appropriate for the API to change to provide an object conforming to some protocol definition instead? I don't like the idea of

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

> On May 16, 2016, at 5:49 PM, Dan Appel wrote: > > Just to clarify: in your example, did you mean for DerivedA and DerivedB to > inherit from Base? Yeah, sorry about that. -Joe > > On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution >

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

Just to clarify: in your example, did you mean for DerivedA and DerivedB to inherit from Base? On Mon, May 16, 2016 at 4:18 PM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Sent from my iPhone > > > On May 16, 2016, at 4:06 PM, Joe Groff via swift-evolution < >

[swift-evolution] [Review] Amendment: SE-0039: Moderning Playground Literals

Original proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md Pull request for modification: https://github.com/apple/swift-evolution/pull/324

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

Regards (From mobile) > On May 16, 2016, at 8:16 PM, Thorsten Seitz via swift-evolution > wrote: > > >>> Am 16.05.2016 um 17:04 schrieb Karl via swift-evolution >>> : >>> >>> internal func _arrayOutOfPlaceReplace >>> >>> (_ source:

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

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

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

> On May 16, 2016, at 2:06 PM, Chris Lattner via swift-evolution > wrote: >> On May 16, 2016, at 11:33 AM, Tim Hawkins > > wrote: >> >> At what point would you consider the Linux product to be viable for >>

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

> On May 16, 2016, at 4:27 PM, Eric Wing via swift-evolution > wrote: > >> I'm not an expert in the Linux communities needs and desires. That said, >> from what I understand, they don’t care at all about ABI stability, since >> everything is typically built from

[swift-evolution] Winding down the Swift 3 release

Hey Chris and team, This is great news. Any news on when/if libdispatch linux compatibility will ship with Swift 3? Thanks again. Haris > Hi Everyone, > > As we get deeper into the Swift 3 release cycle, we’re beginning to have a more precise understanding about what the release will shape up

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

On May 16, 2016, at 9:03 PM, Haris Amin wrote: > Hey Chris and team, > > This is great news. Any news on when/if libdispatch linux compatibility will > ship with Swift 3? Hi Haris, That is still the goal - I know that many folks are intensely interested in making this

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

This sounds like a good idea. -Matt > On May 10, 2016, at 03:43, Geordie Jay via swift-evolution > wrote: > > >> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution >> >: >> >> >>> What is your

[swift-evolution] [Proposal]Simple pattern matching with Horspool algorithm

public extension CollectionType where Index : RandomAccessIndexType { @warn_unused_result func matchWith(pattern: C, @noescape isEquivalent: (Generator.Element, Generator.Element) throws -> Bool) rethrows -> Index? { let pattern_count = pattern.count.toIntMax() if

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

> Am 16.05.2016 um 21:29 schrieb Thorsten Seitz via swift-evolution > : > > >>> Am 15.05.2016 um 10:57 schrieb Adrian Zubarev via swift-evolution >>> : >>> >>> I think an important point is that `all<>` should NOT be restricted to >>>

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

Hi, I’m a +1 on the proposal, I think it’s a no brainer, but I do have one question... What is the reasoning behind repeating the module name in the type name? e.g we have `Dispatch.DispatchQueue`. Why not `Dispatch.Queue`? It seems a bit pointless for the Swift team to go to all that effort

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

> On May 15, 2016, at 1:53 PM, Dave Abrahams wrote: > > > on Fri May 13 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 13, 2016, at 9:19 AM, Dave Abrahams wrote: >>> >>> on Mon May 09

Re: [swift-evolution] Union instead of Optional

I can understand this proposal nite and I don't really think they're related to enums at all. You can today achieve the very same behaviour using an empty protocol. protocol P { } class A : P { } class B : P { } struct C : P { } func test(value : P) { } IMO, the proposed syntax will only

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

-1 for all the reasons given so far. Foundation is not a Swift API and the NS prefixes help users understand that. Until Foundation gets an API rewrite that makes it feel native in the Swift ecosystem, it should be made very clear that it is a legacy API and not necessary following Swift best

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

We (you) shouldn't remove the NS prefixes from most of the classes in the proposal. I agree with the reasons the other naysayers have given, but I'll try to restate them in my own words. Swift needs a better namespace/import system before these classes should lose the NS prefix. Right now, you

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

+1 All the best, Nicholas Linked in: http://lnkd.in/328U22 On Mon, May 16, 2016 at 7:27 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri May 13 2016, Joe Groff wrote: > > >> On May 13, 2016, at 9:13 AM, Rob Napier via

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

But don't you mean the union type of all possible Collection types when you write Any? I suggested `all<>` for the intersection type, and `any<>` for the union type, so that would be the same, wouldn't it? -Thorsten Am 17.05.2016 um 07:10 schrieb Brent Royal-Gordon via swift-evolution

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

> We've been over this a few times before on the list. I personally like naming > this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and > "AnySequence". I also see Thorsten (and in the past Brent's?) argument for > calling it "all" or "All", because it's enforcing multiple

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

On 5/16/16, Chris Lattner wrote: > On May 16, 2016, at 2:27 PM, Eric Wing via swift-evolution > wrote: >>> I'm not an expert in the Linux communities needs and desires. That >>> said, >>> from what I understand, they don’t care at all about ABI

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

> > Hi Patrick, > FYI, we’re very likely to remove this special behavior for operators, by > making operator requirements only find operators declared in a conforming > type. This would eliminate the special case for operators that exists now, > and has other advantages as well. Check out this

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

> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution > wrote: > > I'm actually tempted to suggest that a conformance should be *mandatory* and > you should have to specify `Any` if you don't have anything more specific to > say about the generic

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

> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution > wrote: > > > on Mon May 09 2016, Matthew Johnson > wrote: > >>> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: >>> >>> >>> on Sat May

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

> Am 14.05.2016 um 17:52 schrieb Tony Allevato via swift-evolution > : > > On 2016-05-10 18:51:29 +, Chris Lattner via swift-evolution said: > >> Hello Swift community, >> The review of "SE-0081: Move where clause to end of declaration" begins now >> and runs

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

> Am 14.05.2016 um 20:19 schrieb Tony Allevato via swift-evolution > : > > On 2016-05-14 16:29:40 +, Haravikk via swift-evolution said: > >> On 14 May 2016, at 16:52, Tony Allevato via swift-evolution >> wrote: >>> To me, this makes

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

+1. Non-type generic parameters can be handled if/when they are proposed after Swift 3. There have to be better ways to encourage proper organization of the elements of a method header than forcing a redundant and non-obvious conformance to 'Any'; if this is mandatory the proposal is fatally

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

> On 16 May 2016, Thorsten Seitz wrote: > > Funny, for me reading a function is quite the other way around: > I prefer to first look at the function name and parameter list to give me an > idea of what the function will do (the parameter names help a lot). > Having instead first to memorize a

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

Funny, for me reading a function is quite the other way around: I prefer to first look at the function name and parameter list to give me an idea of what the function will do (the parameter names help a lot). Having instead first to memorize a list of types with all their constraints just builds

[swift-evolution] [Idea] "guard not let" optional binding

I've occasionally hit this problem too, but I don’t think it warrants a language addition, as it can be overcome in other ways. I would move the expensive calculation into its own private method and rewrite your example like this: return cachedValue ?? calculatedValue() In my opinion that would

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

I’ve rewritten my proposal towards the Generic Manifesto for Swift 3. I’ve polished a lot of thoughts to make everything as clear as possible. I still have to write Motivation and Proposed solution, but everything else seems to be rock solid - I’d say. Again `All<>` should not intersect but

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

on Mon May 16 2016, Tyler Fleming Cloutier wrote: >>> Super interesting talk! >>> >>> But consider: isn't a single value type able to represent *multiple* >>> ethereal types? >> >> “ethereal?” Does he really use that term? I don't know what it means. > > He does pretty frequently. He also

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

Having to declare conformance to `Any` is just noise and should *not* be mandatory IMHO. -Thorsten > Am 16.05.2016 um 07:59 schrieb Pyry Jahkola via swift-evolution > : > > >> On 16 May 2016, at 01:45, Brent Royal-Gordon via swift-evolution >>

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

on Sun May 15 2016, Tyler Fleming Cloutier wrote: >> This implies, therefore, that if salient attributes *define* the >> immutability of the value type, then the public interface is not >> guaranteed to be immutable, since it is allowed to include >> non-salient attributes. For example, a

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

Yes. The suggested implementation does use min/max: https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design - Luis On Sun, May 15, 2016 at 3:42 PM, Maximilian Hünenberger < m.huenenber...@me.com> wrote: > I

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

> On May 15, 2016, at 11:17 PM, Tyler Fleming Cloutier via swift-evolution > wrote: > >> >> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Mon May 09 2016,

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

on Sun May 15 2016, Tyler Fleming Cloutier wrote: > On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution > wrote: > > on Mon May 09 2016, Matthew Johnson wrote: > > On May 8, 2016, at 1:51 AM, Dave Abrahams >

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

> On May 15, 2016, at 11:39 PM, Dave Abrahams wrote: > > > on Sun May 15 2016, Tyler Fleming Cloutier wrote: > >>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >>on Mon May 09 2016, Matthew Johnson

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

On May 16, 2016, at 12:45 AM, Brent Royal-Gordon via swift-evolution wrote: >> Being able to let the developer decide how to place relevant type >> information with the freedom of being able to keep some/all/none type >> information local and some/none/all extra

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

Regards (From mobile) > On May 16, 2016, at 8:17 AM, Tyler Fleming Cloutier via swift-evolution > wrote: > > >> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon May 09 2016, Matthew Johnson

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

Regards (From mobile) > On May 16, 2016, at 8:39 AM, Dave Abrahams via swift-evolution > wrote: > > >> on Sun May 15 2016, Tyler Fleming Cloutier wrote: >> >>On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >>

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

> On May 16, 2016, at 2:16 AM, Dave Abrahams wrote: > > > on Mon May 16 2016, Tyler Fleming Cloutier wrote: > Super interesting talk! But consider: isn't a single value type able to represent *multiple* ethereal types? >>> >>> “ethereal?” Does he

Re: [swift-evolution] Union instead of Optional

This doesn't explain how I can use 'value' once an A() is passed into the function: func input(value: (A | B | C)) { } If A, B, and C are not related via protocol or class inheritance, then there is almost nothing you can do with value. Otherwise you still need to test against the concrete

Re: [swift-evolution] Union instead of Optional

> On 16 May 2016, at 11:17, Austin Zheng via swift-evolution > wrote: > > If A, B, and C are not related via protocol or class inheritance, then there > is almost nothing you can do with value. Otherwise you still need to test > against the concrete type using a

Re: [swift-evolution] Union instead of Optional

Precisely. To me unions are to enums with associated type the same way tuples are to structs. One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use,

  1   2   >