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

I don't believe that was the case with the semicolons in the original for;; loop, was it? On Fri, May 27, 2016 at 20:37 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On May 27, 2016, at 7:22 PM, Erica Sadun wrote: > > >

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

I haven't had time to carefully read this whole thread, but I don't think I agree that this syntax is "uglier". Isn't it true that semicolons are used regularly in English; that they delimit separate clauses, boolean or otherwise; and that the proposed syntax mirrors English grammar pretty well

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

A different way of layering could be allowing value types to be composed, where the outer type inherits the inner member’s properties and methods. Let’s say you want only fields ‘contentID’ and ‘contentData' to participate in equality and hashing, but not ‘revisionID': struct ContentInfo :

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

Thanks, I like "Lossless" too. Further suggestions on naming would be appreciated from anyone. Austin > On May 27, 2016, at 9:03 PM, Xiaodi Wu wrote: > > This looks good. I like your use of the term "lossless"; perhaps we can use > it consistently, i.e.

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

This looks good. I like your use of the term "lossless"; perhaps we can use it consistently, i.e. LosslessStringConvertible. The implication by comparison would be that CustomStringConvertible makes no guarantee of losslessness. On Fri, May 27, 2016 at 23:52 Austin Zheng via swift-evolution <

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

I'd hope not. You can't guarantee String -> Double -> String roundtripping, but Double -> String -> Double should be lossless. On Sat, May 28, 2016 at 00:11 Jacob Bandes-Storch wrote: > Does "lossless" preclude floating-point numbers from being printed in > decimal unless

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

I was using the word that the proposal author even used! Couldn't the same be said for the comma though? Sent from my iPad > On May 27, 2016, at 10:48 PM, Jacob Bandes-Storch wrote: > > I haven't had time to carefully read this whole thread, but I don't think I > agree

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

Hello swift-evolution, I've put together a preliminary v2 of the proposal, taking into account feedback expressed on this thread. I would appreciate any comments, suggestions, or criticisms.

Re: [swift-evolution] [Pitch] Circling back to `with`

Just some alternate naming suggestions for with() and withVar(), as the naming guidelines suggest -ed/-ing: withVar altered() // Changes a value copy / reference and returns it mutated() // Or this, but uses value-specific term ‘mutate’ with inspect() // Works with an immutable copy, has

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

Does "lossless" preclude floating-point numbers from being printed in decimal unless they are exactly representable? On Fri, May 27, 2016 at 9:04 PM Austin Zheng via swift-evolution < swift-evolution@swift.org> wrote: > Thanks, I like "Lossless" too. Further suggestions on naming would be >

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

> On May 27, 2016, at 7:50 PM, Xiaodi Wu wrote: > > I don't believe that was the case with the semicolons in the original for;; > loop, was it? No, I don’t believe so, but that’s gone now. And it is pretty uncommon to see `for` loop clauses on multiple lines. Not so

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

As a *user* of the language, I find it a little disconcerting that we would make the syntax uglier just to serve the grammar. Where is the benefit to the user with this? Especially at the cost of making it slightly uglier? And sorry, but what is a boolean assertion? :embarrassed face: Brandon

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

Is there any possibility we can break from this? Especially as: 1. ValuePreservingStringConvertible expects its description to be value preserving, but current Cocoa implementations are not. 2. ‘Description’ doesn’t really convey the meaning of ‘value preserving’ in my mind, but is a valuable

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

> https://github.com/austinzheng/swift-evolution/blob/az-edit-89/proposals/0089-rename-string-reflection-init.md I prefer the more conservative and backwards-compatible option of using `description` and conforming `ValuePreservingStringConvertible` to `CustomStringConvertible`. This is for

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

Some feedback: I wonder if ValuePreservingStringConvertible having an initializer restricts its use case at all? Plus, ValuePreservingStringConvertible seems very similar to RawRepresentable with a RawValue of String. Lossless sounds nice to me. Or ‘canonical’ I had wondered, but lossless

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+ 1 from me as well for the already stated reasons. - Dennis > On May 28, 2016, at 2:15 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution >

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

I don't recall whether it was in this thread or another that this point was made by the core team, but if I'm remembering correctly: it was shared that the protocol is now called CustomStringConvertible because conforming types provide a *custom* description, not merely an ordinary description.

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1. Completely agree with Brent's views here. On 28 May 2016, at 9:15 AM, Brent Royal-Gordon via swift-evolution wrote: >> The idea is simple: >> >>• Can we make return keyword optional in cases like this? >>• Shouldn’t this behave like @autoclosure or

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

> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution > wrote: > > Second, I have really gotten use to not needing to use semicolons, and this > proposal seems to use/require them in very common situations. > > After shedding the requirement of

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

Sent from my iPad On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution wrote: >> The idea is simple: >> >>• Can we make return keyword optional in cases like this? >>• Shouldn’t this behave like @autoclosure or @noescape? > > This actually

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

Sent from my iPad > On May 27, 2016, at 7:13 PM, Erica Sadun via swift-evolution > wrote: > > >> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution >> wrote: >> >> Second, I have really gotten use to not needing to use

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

> On May 27, 2016, at 6:19 PM, Matthew Johnson wrote: >>> Also, can someone refer me to an example of this statement: "This proposal >>> resolves this problem by retaining commas as separators within clauses (as >>> used elsewhere in Swift) and introducing semicolons to

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

> guard > x == 0 && a == b && c == d && > let y = optional, w = optional2, v = optional 3 && > z == 2 > else { ... } > > Figuring out where to break the first line into expression and into condition > (after the `d`) could be very challenging to the compiler. I'm not sure it is. `let` and

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

> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon > wrote: > >> guard >> x == 0 && a == b && c == d && >> let y = optional, w = optional2, v = optional 3 && >> z == 2 >> else { ... } >> >> Figuring out where to break the first line into expression and into >>

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

Sent from my iPad > On May 27, 2016, at 7:22 PM, Erica Sadun wrote: > > >> On May 27, 2016, at 6:19 PM, Matthew Johnson wrote: Also, can someone refer me to an example of this statement: "This proposal resolves this problem by

Re: [swift-evolution] Enhanced existential types proposal discussion

This is a good point. "a.Element" is not an existential, it is a concrete type whose value is not known at compile time. So there is nothing in principle stopping it from being passed into a generic function. This would also allow you to do thing like e.g. make an Array of a.Elements, which

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 4:20 AM, Matthew Johnson via swift-evolution > wrote: > > >> On May 26, 2016, at 8:25 PM, Austin Zheng via swift-evolution >> wrote: >> >> Hi swift-evolution, >> >> For those who are interested I'd like to

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 26.05.2016 um 22:07 schrieb Matthew Johnson via swift-evolution > : > > > > Sent from my iPad > > On May 26, 2016, at 2:49 PM, Austin Zheng via swift-evolution > > wrote: > >> I alway enjoy hearing

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

I’m not sure about this, as restricting anything by OS generally makes me uneasy; where possible we should always try to restrict code by availability and version of modules, as these will indicate the actual features that a platform should support. Part of the problem is that we can’t

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

That's a good point. I still recommend having "Uninterpolable" protocol which could be then applied on any type. Unfortunately, this would require to introduce some kind of a reflection API on the function type :-/ I'll think about it further today and will try to submit a final version of the

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 1:12 AM, Thorsten Seitz wrote: > >> Am 26.05.2016 um 22:07 schrieb Matthew Johnson via swift-evolution >> >: >> >>> >>> > > With Joe’s information about unbound associated types still

Re: [swift-evolution] [Pitch] Property reflection

You made me think about JNI and now I am sad... You monster :P. Sent from my iPhone > On 27 May 2016, at 08:54, L. Mihalkovic via swift-evolution > wrote: > > It might be good to learn from the mistakes java made with its reflection API > because it might help

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 26.05.2016 um 22:44 schrieb Austin Zheng via swift-evolution > : > > (inline) > > On Thu, May 26, 2016 at 12:22 PM, David Hart > wrote: > Hi Austin, > > I never had te occasion to say thanks for the work you have

Re: [swift-evolution] [Pitch] Property reflection

The private(reflectable) sounds reasonable, however, what about internal? It's impossible to include it in an invocation from within the module, but not including it when invoked from outside. Would the behavior on private vars be non-reflectable by default and internal vars would be

Re: [swift-evolution] [Pitch] Property reflection

(inline) > On May 27, 2016, at 12:54 AM, L. Mihalkovic > wrote: > > It might be good to learn from the mistakes java made with its reflection API > because it might help avoid facing the impedence mismatch java faced a couple > years ago when they tried to model

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 3:07 AM, L. Mihalkovic > wrote: > > > >> On May 27, 2016, at 4:20 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >>> On May 26, 2016, at 8:25 PM, Austin Zheng via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Personally I think `&` is more lightweight (and it is established in other languages like Ceylon and Typescript) and `where` is more expressive (and established in Swift for introducing constraints), so I would stay with these. -Thorsten > Am 27.05.2016 um 14:34 schrieb Vladimir.S

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution > wrote: > > I wonder how the views would work with the value semantic of structs. Not all value types have value semantics. It's important to not forget that. I would like to see a

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 3:18 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 27, 2016, at 3:07 AM, L. Mihalkovic > wrote: > >> >> >> On May 27, 2016, at 4:20 AM, Matthew Johnson via

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Late response! As-specified, although I understand the *motivation* for this suggestion, I can’t support the specific proposal whatsoever. That said, I do think there’d be a lot of value in a way to add “convenience type predicates” (terrible name, please improve!) to declarations, so that

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution > wrote: > > From the point of view of the type system `P & Q` is an anonymous supertype > of `P` and `Q`. > This would be just the same if the syntax was `Any`. I don’t see a > semantic

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 14:13 schrieb Vladimir.S : > > Support Thorsten's opinion. I believe P & Q much more clear and expressive, > don't confuse if we should understand comma separation as 'and' action or > 'or' (in case Any) and don't confuse that is not a list of

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I agree. This also isn't the only case where a 'deriving' keyword would come in handy. I'm mulling a proposal for a compiler-derived enum, and I worried the magic-ness of it would face strong opposition. Having a 'deriving' keyword is the perfect solution, since it becomes explicit. > On

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 9:22 AM, Anders Ha wrote: > >> >> On 27 May 2016, at 9:30 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution >>

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 6:15 AM, Leonardo Pessoa wrote: > > I'm also not fond of allowing what could be called a backdoor to accessing > privates and intervals too but has anyone thought of enhancing the Mirror > class instead of having something totally

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 8:25 AM, Charlie Monroe wrote: > >> This one is tricky. I am generally be opposed to any way to get around >> access control. But people are going to implement things like serialization >> using this which may require

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad On May 27, 2016, at 5:25 AM, Brent Royal-Gordon wrote: >> This one is tricky. I am generally be opposed to any way to get around >> access control. But people are going to implement things like serialization >> using this which may require access

Re: [swift-evolution] [Pitch] Property reflection

I think this proposal should “simmer" until we know what property behaviors will look like (or find out they are never happening, etc.). The interaction with “property behaviors” seems likely to be quite subtle, even for something simple like `lazy`. For sake of argument, let’s say that a

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 26, 2016, at 9:44 PM, Austin Zheng > wrote: > >> Thanks, as always, for the thoughtful

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 27.05.2016 um 10:45 schrieb Austin Zheng : > > As far as I understand it (and the core team as well, judging from their > posts), an existential is just a type defined by an interface of some sort > ("there exists a type that is capable of X, Y, and Z"), and you can

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 26, 2016, at 9:44 PM, Austin Zheng wrote: > > Thanks, as always, for the thoughtful feedback. (inline) > >> On Thu, May 26, 2016 at 7:20 PM, Matthew Johnson >> wrote: >> >> >> These names are a good place to start

Re: [swift-evolution] [Pitch] Property reflection

Here’s an idea using enums. They work similar to a lens, where they are separate from the actual instance. So you can convert string keys or validate potential values without needing an instance. The PropertyIdentifierProtocol is implemented by an string representable enum, piggy backing on

Re: [swift-evolution] [Pitch] Property reflection

> I believe CoreData uses synthesized computed properties that access values > stored in an internal row cache (or something along those lines). Yeah, by creating a subclass of the original class, but that's not the point - accessing private variables can have legit uses. Yes, it can be abused,

Re: [swift-evolution] [Pitch] Property reflection

> On 27 May 2016, at 9:30 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 27, 2016, at 5:45 AM, Anders Ha via swift-evolution > > wrote: > >> I wonder how the views would work with the

Re: [swift-evolution] [Pitch] Property reflection

Sent from my iPad > On May 27, 2016, at 2:25 AM, Austin Zheng wrote: > > Would you be willing to elaborate? Are you thinking of model objects whose > properties are all completely hidden using 'private' and whose APIs are > available only through methods? What if

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

If you have to specify Equatable / Hashable, then you can get an error if the automatic implementation failed, due to a member also not being Equatable/Hashable. If it’s automatic, then it will just quietly fail, making problems harder to know about and track. It will also always add to the

Re: [swift-evolution] [Pitch] Property reflection

> This one is tricky. I am generally be opposed to any way to get around > access control. But people are going to implement things like serialization > using this which may require access to private properties. I think we want > to try to understand the consequences of different options and

Re: [swift-evolution] [Pitch] Property reflection

I wonder how the views would work with the value semantic of structs. The view types proposed, if not being a compiler magic, would need to have a reference to the reflected instance. They are also escapable unless special rules for the view types are enforced. So… perhaps we would want less

Re: [swift-evolution] [PITCH] ADD AN @RESTRICTED DECLARATION ATTRIBUTE

Named platforms always take precedence over the *, in essence. Sent from my iPad > On 27 May 2016, at 15:44, Xiaodi Wu wrote: > > I dislike `@restricted` for several reasons. First of all, but for a desire > for brevity, @available and @restricted would do the same

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

I agree. These are different proposals that can coexist but I think they should be evaluated separately by the community. -Original Message- From: "Vladimir.S via swift-evolution" Sent: ‎27/‎05/‎2016 08:05 AM To: "Charles Srstka"

Re: [swift-evolution] Enhanced existential types proposal discussion

Thanks! And thanks for your great work on this proposal! -Thorsten > Am 27.05.2016 um 10:10 schrieb Austin Zheng : > > This is a good point. "a.Element" is not an existential, it is a concrete > type whose value is not known at compile time. So there is nothing in >

Re: [swift-evolution] Enhanced existential types proposal discussion

Thank you for all your great feedback! Let me try rephrasing what I said, because it wasn't very clear. Apologies. NSView is not an existential, like you said. Any<...> syntax is, as far as we've seen, always used for existential types. "Any" *looks* like an existential because it has the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

It seem to me we are debating the how of a what that has not been defined. The root question behind all these alternatives seems to be to decide if the existential-ness should be carried by a 'container' that is then refined internally, or derived from the presence of the free-floating

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> The suggested solution based on 'accessor' - will create assotiated > properties each time the enum instace created, for each instance of enum type. No; property accessors would be either computed or constant (so that all instances of a given case can share storage). This is much the way they

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 25.05.2016 um 17:03 schrieb Matthew Johnson via swift-evolution > : > > >> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution >> > wrote: >> >>> >>> On May 25, 2016, at 10:01 AM, Austin

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

We could just write let x: P & Q instead of let x: Any let x: Collection where .Element: P instead of let x: Any let x: P & Q where P.T == Q.T instead of let x: Any let x: P & Q & R instead of let x: Any let x: Collection instead of let x: Any This

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 25.05.2016 um 22:16 schrieb Matthew Johnson via swift-evolution > : > > >> On May 25, 2016, at 2:22 PM, Brent Royal-Gordon >> wrote: >> >>> But if we are going to remove the ability to use typealiases bound to `Any` >>> in constraints

Re: [swift-evolution] [Pitch] Property reflection

When compared to the java language itself, the reflection API was close-enough but lossy. So when it came time to implement javax.lang.model over reflection there were naturally gaps (similar notions were wrongly viewed as different problems). Narrowed down and translated back to swift, a

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I agree, I think there is no need for deriving/synthesizes, but also, no need to specify Equatable, Hashable. They should get the functionality by default but allow for override and customization. > On May 26, 2016, at 11:02 PM, Patrick Smith wrote: > > I don’t

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 26, 2016, at 12:03 PM, Matthew Johnson wrote: > > Austin, this brings to mind the question of how you will handle conflicts if > the type defines an instance member with the same name as the asociatedtype. > This should be uncommon due to capitalization

Re: [swift-evolution] Enhanced existential types proposal discussion

Considering how I interpret (i.e. I could be totally wrong) sentiments expressed by the core team on expressiveness, I would wager that duck typing is NOT on their agenda for Swift. > On May 26, 2016, at 8:56 PM, Adrian Zubarev via swift-evolution > wrote: > >

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

Correct me if I'm wrong, but this idea with accessors is not the same as static properties for each case. The one of ideas of initial proposal - static(!) values would be created only once and it is important in case it is expensive to create such value(or if should be created only once per

Re: [swift-evolution] [Pitch] Property reflection

I'm also not fond of allowing what could be called a backdoor to accessing privates and intervals too but has anyone thought of enhancing the Mirror class instead of having something totally new? I've tried using it once but in the end it wasn't necessary for what I needed to do. An opt-in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Support Thorsten's opinion. I believe P & Q much more clear and expressive, don't confuse if we should understand comma separation as 'and' action or 'or' (in case Any) and don't confuse that is not a list of gerenic types. Also such syntax is very lightweight and very readable and

Re: [swift-evolution] Enhanced existential types proposal discussion

As far as I understand it (and the core team as well, judging from their posts), an existential is just a type defined by an interface of some sort ("there exists a type that is capable of X, Y, and Z"), and you can put any value of a type that meets that interface in the existential. The

Re: [swift-evolution] Enhanced existential types proposal discussion

> // With the new collection model (SE-0065), indices are simply Comparable > now > // Okay to cast from x.Index to Comparable > let a = anIndex as Comparable > > // Not okay to cast from Comparable to y.Index > let b = a as y.Index > > // This should be okay. We may want to break

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 25.05.2016 um 21:22 schrieb Brent Royal-Gordon via swift-evolution > : > >> But if we are going to remove the ability to use typealiases bound to `Any` >> in constraints we need to introduce an alternative mechanism for factoring >> out constraints (hopefully a

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

I believe the only 'fix' here is to prevent string interpolation for anything that is not base types like String, Integer, Double, Boolean or that is explicitly provides textual(not for debugging) representation. For all others like function, Optional etc leave only debug string

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Btw, in case we have `where` keyword in syntax related to types/protocols (when defining constrains. and not some symbol like '>>'.. don't know, for example), why we can't have 'and' keyword also when discuss the syntax of type/protocol conjunction? I.e. let x: P and Q let x: P and Q where

Re: [swift-evolution] Enhanced existential types proposal discussion

> Am 27.05.2016 um 10:30 schrieb Austin Zheng : > > Thank you for all your great feedback! > > Let me try rephrasing what I said, because it wasn't very clear. Apologies. > > NSView is not an existential, like you said. > > Any<...> syntax is, as far as we've seen,

Re: [swift-evolution] [Pitch] Property reflection

I'm talking of model objects that serializes certain properties (not necessarily all) that should have their setter be private/hidden for encapsulation reasons: struct Person { private(set) var birthdate: NSDate } I'm not a fan of adding an attribute like private(reflectable). The proposal

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution > wrote: > > >> On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution >> wrote: >> I alway enjoy hearing your ideas. This is quite

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

>From the point of view of the type system `P & Q` is an anonymous supertype of >`P` and `Q`. This would be just the same if the syntax was `Any`. I don’t see a semantic difference here. Whether that is a "container“ or not seems to be an implementation detail to me but should have

Re: [swift-evolution] [Pitch] Property reflection

> On May 27, 2016, at 9:50 AM, L Mihalkovic > wrote: > >> >> On May 27, 2016, at 4:05 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> >> >> Sent from my iPad >> >> On May 26, 2016, at

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution > wrote: > > Personally I think `&` is more lightweight (and it is established in other > languages like Ceylon and Typescript) and `where` is more expressive (and > established in Swift for

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 3:45 AM, Austin Zheng via swift-evolution > wrote: > > As far as I understand it (and the core team as well, judging from their > posts), an existential is just a type defined by an interface of some sort > ("there exists a type that is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPad > On May 27, 2016, at 11:07 AM, Thorsten Seitz wrote: > > >>> Am 27.05.2016 um 16:54 schrieb Matthew Johnson : >>> >>> >>> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution >>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

Moving this review to where it belongs. Not sure who renamed it to SE–0089?! --  Adrian Zubarev Sent with Airmail Am 27. Mai 2016 bei 16:58:16, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: On May 27, 2016, at 3:57 AM, Thorsten Seitz wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 3:57 AM, Thorsten Seitz wrote: > >> >> Am 25.05.2016 um 17:03 schrieb Matthew Johnson via swift-evolution >> >: >> >> >>> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 6:16 AM, Thorsten Seitz wrote: > > >> Am 25.05.2016 um 21:22 schrieb Brent Royal-Gordon via swift-evolution >> : >> >>> But if we are going to remove the ability to use typealiases bound to `Any` >>> in constraints we

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

I like the design strategy, but I’m having a hard time seeing the value of `ValuePreservingStringConvertible`; it’d be easier to evaluate the need for it with some concrete examples of types with `description` implementations that: - aren’t value-preserving - would cause problems if

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 27, 2016, at 4:52 PM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >> From the point of view of the type system `P & Q` is an

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 27, 2016, at 10:37 AM, plx via swift-evolution > wrote: > > >> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >> > wrote: >> >> A `deriving` keyword, at the very least, is pretty

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 27.05.2016 um 18:28 schrieb Matthew Johnson : > > > > Sent from my iPad > > On May 27, 2016, at 11:18 AM, Austin Zheng > wrote: > >> Here's a strawman idea. >> >> What if we go with '&' and 'where', but we

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

I think the parentheses are the fundamental aspect of the suggestion :). Let me turn the question around. If tuples were declared like this: let myTuple : Int, String, Bool = (10, "hello", false) would the type be more or less readable? I find it a lot more difficult to immediately parse than:

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 27, 2016, at 6:02 AM, L. Mihalkovic > wrote: > > > On May 26, 2016, at 10:56 PM, Matthew Johnson via swift-evolution > > wrote: > >> >>> On May 26, 2016, at 3:39 PM, Adrian Zubarev via

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution > wrote: > > A `deriving` keyword, at the very least, is pretty explicitly *not* an > all-or-nothing situation. If you want to define equality/hashability for your > type manually, don't use `deriving`.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 25, 2016, at 7:07 AM, Thorsten Seitz via swift-evolution > wrote: > This is unfortunate, because then the meaning of "existential" and > "non-existential" in Swift are just the opposite of their respective meaning > in standard terminology :-( I don't know

Re: [swift-evolution] [Idea] Switch Statement with Optional Binding

Nice! However, the case statements may increase as shown below and I was wondering if it will still be worth it(Greetings core team!) in adding some syntactic sugar as aforementioned... switch cityIDs["Paris"] { case let .Some(parisCityID) where 0..<3 ~= parisCityID: print("Paris city ID:

Re: [swift-evolution] [Pitch] Property reflection

I think there is a consensus forming that we probably don't yet know enough about Swift's future capabilities to nail down specific designs yet. (Not that I want to stop people from talking about them if they wish.) However, now that there is a conversation topic about reflection, I also wanted

  1   2   >