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

On Sun, May 29, 2016 at 11:23 PM, Brent Royal-Gordon via swift-evolution wrote: > There are *very* few conformances to Streamable in the standard library—just > Character, String, and UnicodeScalar. I think that Streamable is for data > that can be *directly* written to an output stream, whereas

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > > But `protected` is quite different from other access levels; it does not > limit the visibility of the symbols, but rather their use. And protocols face > the same sort of problem as classes, where certain membe

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

> Thanks Chris. I just meant where is that string going? > > To a developer -> CustomDebugStringConvertible / Reflection > To standard output -> Streamable > To a user -> NSLocalizedString — no protocol (yet?) > To an API / for serialisation -> LosslessStringConvertible > To a playground -> Custom

Re: [swift-evolution] [Proposal] Protected Access Level

That's a cool hack! For a lighter way to distinguish overridable methods that one shouldn't ordinarily call, did anyone consider approximating "protected" (or as called in Objective-C speak, "private extension") methods with public class methods? public class UIView { public class f

Re: [swift-evolution] [Proposal] Protected Access Level

I have to agree with Charlie Monroe that while this is doable, it's clear this is a workaround to a problem, not a viable long term language solution. - Rod Sent from my iPhone > On 30 May 2016, at 2:49 PM, Callionica (Swift) > wrote: > > I've written up how to provide protected access cont

Re: [swift-evolution] [Pitch] #warning

> As to #warning, Swift’s use of warnings are significant different than the > use in C. In C compilers, many of the warnings produced *should* be errors, > but can’t be because that effects language conformance and could break a > large body of code. The example I've mentioned with #error, d

Re: [swift-evolution] [Proposal] Protected Access Level

That's a nice workaround - but nice in a sense that that it's a hack, not a solution IMHO. > On May 30, 2016, at 6:49 AM, Callionica (Swift) via swift-evolution > wrote: > > I've written up how to provide protected access control for Swift code today > here: > > http://www.callionica.com/de

Re: [swift-evolution] [Pitch] #warning

FWIW, I'm also in favor of adding #error to the language. It would be good to express invariants that the compiler can't know about, like mutually exclusive build config options that affect code downstream. I'm definitely seeing how #warning might conflict with the goals of Swift's warnings. I

Re: [swift-evolution] [Proposal] Protected Access Level

Cool! -Thorsten > Am 30.05.2016 um 06:49 schrieb Callionica (Swift) via swift-evolution > : > > I've written up how to provide protected access control for Swift code today > here: > > http://www.callionica.com/developer/#swift-protected > > No compiler changes necessary for this technique

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

Great! Thanks! -Thorsten > Am 29.05.2016 um 22:29 schrieb Austin Zheng : > > I'll add it to the "Future Directions" section. I feel that's the best place > to put it, since there's no guarantee that Swift will get a bottom type, and > because making existentials to work with a bottom type wou

Re: [swift-evolution] [Proposal] Protected Access Level

I've written up how to provide protected access control for Swift code today here: http://www.callionica.com/developer/#swift-protected No compiler changes necessary for this technique and it distinguishes between methods that can only be overridden and methods that can be both called and overrid

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

Thanks Chris. I just meant where is that string going? To a developer -> CustomDebugStringConvertible / Reflection To standard output -> Streamable To a user -> NSLocalizedString — no protocol (yet?) To an API / for serialisation -> LosslessStringConvertible To a playground -> CustomPlaygroundQuic

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

> On May 29, 2016, at 10:13 PM, Matthew Johnson wrote: > > On May 29, 2016, at 9:43 PM, Charles Srstka > wrote: > >>> On May 29, 2016, at 9:20 PM, Matthew Johnson >> > wrote: >>> >>> On May 29, 2016, at 5:43 PM, Charles Srstka via

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 10:14 PM, Austin Zheng wrote: > > >> On May 29, 2016, at 8:04 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution >>> wrote: >>> >>> I significantly rewrote the proposal t

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

Sent from my iPad > On May 29, 2016, at 9:43 PM, Charles Srstka wrote: > >> On May 29, 2016, at 9:20 PM, Matthew Johnson wrote: >> >> On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution >> wrote: >> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: I think the

Re: [swift-evolution] Variadic generics discussion

Umm...all its members are *values*. Sorry. > On May 29, 2016, at 8:14 PM, Austin Zheng wrote: > >> >> On May 29, 2016, at 8:04 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution >>

Re: [swift-evolution] Variadic generics discussion

> On May 29, 2016, at 8:04 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I significantly rewrote the proposal to take into account as much feedback >> as I could. (Many

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 7:36 PM, Austin Zheng via swift-evolution > wrote: > > I significantly rewrote the proposal to take into account as much feedback as > I could. (Many things, like syntax, haven't been changed yet, but will be in > a forthcoming version.) > > What I d

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

> On May 29, 2016, at 9:20 PM, Matthew Johnson wrote: > > On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>> On May 29, 2016, at 5:16 PM, Austin Zheng >> > wrote: >>> >>> I think the problem here is th

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

Sent from my iPad > On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution > wrote: > >> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: >> >> I think the problem here is that P == P is true, but P : P is not (a >> protocol does not conform to itself). > > But if you have a vari

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

+1 from me as well. On Sun, May 29, 2016 at 18:39 David Hart via swift-evolution < swift-evolution@swift.org> wrote: > +1 again. > > On 29 May 2016, at 21:39, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On May 29, 2016, at 3:55 AM, Haravikk wrote: > > On May 27, 2

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

> On May 29, 2016, at 3:39 PM, Chris Lattner via swift-evolution > wrote: > > I can definitely respect the position that “where” feels more readable than a > semicolon, it certainly provides a more “fluent” style. > > That said, the existing Swift 2 syntax was inconsistent about this too: if

Re: [swift-evolution] [Proposal] Protected Access Level

Brent, You make a very good point about the fact internal is not necessarily the same as subclass, something I hadn’t considered. I think that the level of exposure these APIs then get - ultimately Public within frameworks - is too unrestricted. At least in Objective-C, we can vet the headers

Re: [swift-evolution] Variadic generics discussion

I significantly rewrote the proposal to take into account as much feedback as I could. (Many things, like syntax, haven't been changed yet, but will be in a forthcoming version.) What I did change: - Renamed 'packs' to 'vectors' - Discussed variadic typealiases a bit, including things like "var

Re: [swift-evolution] [Proposal] Protected Access Level

> 1. Methods and properties that only subclasses must access, but other code > has no business updating. An example of this UIGestureRecognizer. State > machine type access is something where external items should not access, but > internal state may require the rights to update. But again, "ex

Re: [swift-evolution] Variadic generics discussion

> On May 29, 2016, at 2:39 AM, Daniel Vollmer via swift-evolution > wrote: > > >> On 29 May 2016, at 02:33, Austin Zheng wrote: >> >>> - I have an argument pack. How would I apply a function taking a single >>> argument to each element in the pack? Go via the tuple? >> >> This is definitel

Re: [swift-evolution] [Proposal] Protected Access Level

I missed the last part when you are talking about bridging TO Objective-C, but Rod Brown answered that very well (thanks). -Van On Sun, May 29, 2016 at 8:50 PM, Vanderlei Martinelli < vmartine...@alecrim.com> wrote: > Hi Leonardo. > > Thank you for your answer. > > I understand your point of vie

Re: [swift-evolution] [Proposal] Protected Access Level

> You seem to be producing a convoluted solution to create a “sharps drawer” > but Swift is supposed to be safe. You shouldn’t access the sharps drawer > there and there are better ways for us to stop you than to simply “trust” the > developer - it’s to do the right thing, and provide a protecti

Re: [swift-evolution] [Proposal] Protected Access Level

Hi Leonardo. Thank you for your answer. I understand your point of view and I agree that it is better to look forward. But today we still have to deal with decades of legacy Cocoa code written using classes. If tomorrow a new set of Cocoa frameworks written in Swift using protocols appears, maybe

Re: [swift-evolution] [Proposal] Protected Access Level

I agree that we should be looking for what makes sense, not just what we’ve seen in other languages. That said, there seems a lot of hate for OOP in general that seems to be clouding people’s vision here. I think that “protected” as a form of access control is exactly what we want: rights that

Re: [swift-evolution] [Proposal] Protected Access Level

Here's demo code for emulating protected in Swift: https://gist.github.com/callionica/19da0763c0b0b4c504fc5f46d07e8ee8 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

I can't reply directly to all the points in this thread, but I will just say that there are ways of emulating protected in the language as it exists today: If the goal is to have functions that can be overridden by subclasses without being called by external classes, you can create a parameter of

Re: [swift-evolution] [Pitch] #warning

Tools like SonarQube can raise a "warning" for comments started with "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be presented as warnings instead of using #warning? And this could be an optional setting as commented would not influence compilation. -Original Messag

Re: [swift-evolution] [Proposal] Protected Access Level

Vanderlei, my point in bringing such topics to this discussion is to make everyone here think if we're trying to really enhance the language within its intended purpose or if we're trying to change the language into something else were familiar with from other languages we work/ed with just beca

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

> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: > > I think the problem here is that P == P is true, but P : P is not (a protocol > does not conform to itself). But if you have a variable, parameter, etc. typed as P, that’s *not* the protocol, since protocols aren’t concrete entities. What

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

+1 again. > On 29 May 2016, at 21:39, Chris Lattner via swift-evolution > wrote: > >> On May 29, 2016, at 3:55 AM, Haravikk wrote: On May 27, 2016, at 12:11 PM, Joe Groff wrote: Hello Swift community, The review of SE-0099 “Restructuring Condition Clauses” begins no

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

I think the problem here is that P == P is true, but P : P is not (a protocol does not conform to itself). I think there was some discussion about it on the original "Completing Generics" thread from March. I'd probably ask on the swift-users list why P can't be made to conform to P, and then p

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

Forgive me if this has already come up, but since we’re talking about fixing generics, I wonder if there is any solution in the pipeline for this problem: -- protocol P { func foo() } struct S: P { func foo() { print("foo") } } func doSomething(c: C) { for each in c { ea

Re: [swift-evolution] [Pitch] #warning

+1 to #warning or optionally(?) emitting something like TODO: more visibly! In past ObjC projects, I have used #warning to confirm the right macros were enabled. I often (1) work around differences between the iOS simulator and device with TARGET_IPHONE_SIMULATOR (+similar) and (2) change API e

Re: [swift-evolution] [Proposal] Protected Access Level

Thank you all for your comments. :-) Well... My goal is to keep the thing really simple and do not start a new "OOP x POP" (or "something" x "other thing") war. "Protected" access level is not a new concept at all (except for the Swift language), so I did not propose anything preposterous. Of co

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

Thanks for everyone participating in this discussion! :) I’ve drafted a formal proposal, it is available here: https://github.com/dennisweissmann/swift-evolution/blob/tuple-destructuring/proposals/-tuple-destructuring.md Please let me know what you think (it would be great if a native speaker

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

I'll add it to the "Future Directions" section. I feel that's the best place to put it, since there's no guarantee that Swift will get a bottom type, and because making existentials to work with a bottom type would be a completely additive change. Austin > On May 29, 2016, at 12:48 PM, Thorste

Re: [swift-evolution] [Pitch] #warning

> On May 29, 2016, at 12:58 PM, Erica Sadun wrote: > One could make a weak argument that #warning/#error/#message make a nice > family of flexible alerts > just because they're kind of what we're used to already. Right: it isn’t a bad thing at all, but it is certainly the case that people ofte

[swift-evolution] Core team review process update

The core team has caught up except for three proposals that have gone through the review period, but which haven’t been decided yet: The details of SE-0086 are still being discussed. The proposal overall is certain to be approved, but the specific list of affected types may or may not change.

[swift-evolution] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md Hello Swift Community, The review of SE-0050: "Decoupling Floating Point Strides from Generic Implementations" ran from May 17...23, 2016. The proposal is returned for revision: There w

Re: [swift-evolution] [Pitch] #warning

> On May 29, 2016, at 1:44 PM, Chris Lattner via swift-evolution > wrote: > > >> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution >> wrote: >> >> I appreciate the sentiment, but I think we should reserve warnings for >> actual compiler diagnostics. > > +1. The IDE should j

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

> Am 29.05.2016 um 18:07 schrieb Austin Zheng : > > >> On May 29, 2016, at 7:04 AM, Matthew Johnson > > wrote: >> >> >> This makes a lot more sense! So you want to be able to use uninhabitable >> types in the contexts of things like collection elements (such co

Re: [swift-evolution] [Pitch] #warning

> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution > wrote: > > I appreciate the sentiment, but I think we should reserve warnings for > actual compiler diagnostics. +1. The IDE should just pick up "// FIXME: “ comments and summarize them as issues. Xcode already shows them

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

> On May 29, 2016, at 3:55 AM, Haravikk wrote: >>> On May 27, 2016, at 12:11 PM, Joe Groff >> > wrote: >>> >>> Hello Swift community, >>> >>> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs >>> through June 3, 2016. The proposal is available

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

The chapter on optionals. Right in the thick of things about if let binding, pattern matching, etc. It's a bit of a digression from the main flow of things. In the PDF version it's p. 87 (at least, by Acrobat's reckoning). On Sun, May 29, 2016 at 15:28 Brandon Knope wrote: > What chapter is this

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

What chapter is this in? I own this great book and would like to see what you are referring to! Thanks, Brandon > On May 29, 2016, at 11:32 AM, Xiaodi Wu wrote: > > I totally agree with Brandon that it makes sense in the context. But I > disagree with you: the behavior certainly isn't consis

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

Fantastic, thanks to both of you. I merged it here: https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md Please let me know if you’d like any ot

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

> On May 28, 2016, at 10:46 PM, Patrick Smith wrote: > > Thanks for replying Chris! > >> On 29 May 2016, at 6:00 AM, Chris Lattner wrote: >> >> 2) If a value wants a better, or more customized, string form, then it >> conforms to CustomStringConvertible. > > > What are the use cases for th

Re: [swift-evolution] [Pitch] Expose assert configuration functions in standard library

Am I understanding correctly that -Onone → _isDebugAssertConfiguration is true -O → _isReleaseAssertConfiguration is true -Ounchecked → _isFastAssertConfiguration is true ? If the goal is to expose the optimization level to user code, might I suggest something like enum Optimi

[swift-evolution] [Pitch] Expose assert configuration functions in standard library

Back in March, I somewhat foolishly agreed to pick up the gauntlet for a series of community-requested proposals centered on build configurations. Requested items included: A way to test for destination platforms like Apple, Linux, Windows, Unix-like, UIKit-supporting, etc A way to test for Sim

Re: [swift-evolution] Variadic generics discussion

This feedback is great. > On May 29, 2016, at 9:00 AM, plx via swift-evolution > wrote: > > Thanks for getting the discussion started with such a thorough initial > writeup. > > My overall concern is this: > > - on the one hand, I *very much* understand—and support—the idea of starting > si

Re: [swift-evolution] [Proposal] Protected Access Level

I'm not opposed to the idea of finer-grained access levels in general, but if the current system is extended, the change imho should be more "holistic": Right now, class hierarchy has no effect on accessibility, and it feels odd to have access level that is different from the others. Doing so wou

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

This is a good list of goals. A few quick comments: I feel like a fundamental question that can be “added” to almost all of these is “how do modules appear for reflection?” EG, for one such example, “Find all the methods on a type”: - can you ask for only methods defined in its “home module” -

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

> On May 29, 2016, at 7:04 AM, Matthew Johnson wrote: > > > This makes a lot more sense! So you want to be able to use uninhabitable > types in the contexts of things like collection elements (such collections > must always be empty but are inhabitable by a single empty instance). It is >

Re: [swift-evolution] Variadic generics discussion

Thanks for getting the discussion started with such a thorough initial writeup. My overall concern is this: - on the one hand, I *very much* understand—and support—the idea of starting simple and adding functionality later - on the other hand, this is *already* a rather complicated proposal syn

Re: [swift-evolution] [Proposal] Protected Access Level

The rust compiler is written in rust… many compilers are bootstrapped and then written in their own language. Looking at the swift language vs C++ features used in the current compiler, I wager it would be a suicide mission to try with Swift 3.0. > On May 29, 2016, at 2:27 PM, Leonardo Pessoa

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

I totally agree with Brandon that it makes sense in the context. But I disagree with you: the behavior certainly isn't consistent. Those are two orthogonal evaluations. Personally, I've never been tripped up by the two different meanings of where clauses and I've used both. Yet, when it was presen

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

Totally agree with Brandon. I don’t think that behavior is inconsistent. -Thorsten > Am 28.05.2016 um 22:18 schrieb Brandon Knope via swift-evolution > : > > Doesn't this contextually make sense though? > > for, when read: > "for each value in collection where some condition is met" do this l

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

Yes, and I’ve been arguing for it being explicit by conforming to the Equatable / Hashable protocol. This would then work the same way as protocol extensions. Protocol extension don’t require a special ‘deriving’ keyword, so I don’t believe there needs to be one here. Just conforming to the prot

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

> Am 28.05.2016 um 22:35 schrieb Chris Lattner : > > >> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: >> >> What about requiring `let` before each binding and `case` before each >> pattern? >> >> guard case let x = a, case let y = b, let z = c, x == y else { … } >> >> Now `let z = c`

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

> On May 29, 2016, at 9:22 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution >> wrote: >> >>> On 27.05.2016 18:37, plx via swift-evolution wrote: >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution

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

Sent from my iPad > On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution > wrote: > >> On 27.05.2016 18:37, plx via swift-evolution wrote: >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> A `deriving` keyword, a

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

> Am 28.05.2016 um 22:04 schrieb Matthew Johnson : > > >> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I’m not happy with that restriction in the proposal: >> >> Existentials cannot be used with generics in the following wa

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

Sent from my iPad > On May 29, 2016, at 8:41 AM, Vladimir.S via swift-evolution > wrote: > > Saw `class` in examples and want to clarify.. Are we discussing auto-deriving > for *value types only*. Or for classes also? > As I understand, there could be some additional questions/issues for thi

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

Haravikk, this *is* the proposal for removing where clauses; changing the rules about commas was the later addition to the discussion. On Sun, May 29, 2016 at 06:55 Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 28 May 2016, at 23:48, Chris Lattner via swift-evolution < >

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

On 27.05.2016 18:37, plx via swift-evolution wrote: On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution mailto:swift-evolution@swift.org>> wrote: A `deriving` keyword, at the very least, is pretty explicitly *not* an all-or-nothing situation. If you want to define equality/hashability

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

Sent from my iPad > On May 29, 2016, at 8:50 AM, Thorsten Seitz wrote: > > >>> Am 28.05.2016 um 22:08 schrieb Matthew Johnson : >>> >>> >>> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution >>> wrote: >>> >>> I’m not happy with that restriction in the proposal: >>> >>> Exi

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

> Am 28.05.2016 um 22:08 schrieb Matthew Johnson : > > >> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I’m not happy with that restriction in the proposal: >> >> Existentials cannot be used with generics in the following wa

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

Saw `class` in examples and want to clarify.. Are we discussing auto-deriving for *value types only*. Or for classes also? As I understand, there could be some additional questions/issues for this feature because of class inheritance. But probably this feature could be discussed for `final` clas

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

An, now I see what you mean. You are right, P ::= ∃ t : P . t is a constrained existential type defining a subtype relationship. Thanks for enlightening me! I haven’t perceived a protocol as an existential up to now, probably because my understanding has come from Haskell where subtyping does no

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

Good point. :) I’ve been thinking if there is a way to still have a shiny and swifty looking syntax which would solve this problem: typealias SomeExistential = existential { constraint UIView constraint ProtocolA constraint ProtocolB.AssociatedType == T var someVar: I

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

Sent from my iPad > On May 29, 2016, at 8:25 AM, Vladimir.S wrote: > > > Should 'deriving' allows us to manually implement protocol requirements? For > example > struct A : deriving Hashable { > var hasValue : Int {...} > } > > Or there should be a compilation error in this case? This sho

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

Should 'deriving' allows us to manually implement protocol requirements? For example struct A : deriving Hashable { var hasValue : Int {...} } Or there should be a compilation error in this case? Right now I feel that if we can have auto-deriving by using current syntax for protocol confor

Re: [swift-evolution] [Proposal] Protected Access Level

Multiple ways for multiple needs. The same way you can support both delegation as well as blocks based callbacks. Sent from my iPhone > On 29 May 2016, at 13:23, Leonardo Pessoa via swift-evolution > wrote: > > You know the default access is was is used for this, right? And in this case > I

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

I think that's the case with enums. You're changing their current behaviour of only having stored values to one in which it's computed (even if only once and then stored). Enums are IMO something that have a static value you know beforehand and can count on. That's why I'm not fond of the access

Re: [swift-evolution] Variadic generics discussion

I hate C++ generics. Just thought about sharing this. > On 29 May 2016, at 9:00 am, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 1:22 AM, Austin Zheng wrote: >> >> Thank you for reading through the proposal! >> >>> On May 28, 2016, at 7

Re: [swift-evolution] [Proposal] Protected Access Level

> attempting to write a Swift compiler in Swift today would probably result in > hard to read/reason about source code. Hmm, I still have to find some time to start working in this... ___ swift-evolution mailing list swift-evolution@swift.org https://

Re: [swift-evolution] [Proposal] Protected Access Level

You know the default access is was is used for this, right? And in this case I don't think they meant it for external subclasses to be able to access this change. I think this is how Swift was meant to work allowing only classes in a certain module to access such "private shared" parts and usin

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 29, 2016, at 9:38 AM, Charlie Monroe via swift-evolution > wrote: > > Ditto - I would love to be able to disallow non-subclasses > accessing/modifying some variables. > > Though, I'm not sure what would be the stand on this from the core team - > according to Apple's blog they've a

Re: [swift-evolution] Variadic generics discussion

Sent from my iPad > On May 29, 2016, at 1:22 AM, Austin Zheng wrote: > > Thank you for reading through the proposal! > >> On May 28, 2016, at 7:41 PM, Matthew Johnson wrote: >> >> These are some very good and clearly articulated examples. Great work! >> This section is important because

Re: [swift-evolution] [Proposal] Protected Access Level

Sent from my iPhone > On 29 May 2016, at 11:30, Brent Royal-Gordon via swift-evolution > wrote: > > There is nothing magical about being a subclass that ought to grant access to > those methods Hello Brent, You must admit that when thinking about the words inheritance and parent/child cla

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

Sent from my iPad > On May 29, 2016, at 12:28 AM, Patrick Smith wrote: > > Yeah I don’t see a problem. It’s the same way that protocol extensions just > work. Think of this automatic synthesis as a really flexible protocol > extension: > > extension Hashable where Members : Hashable { > v

Re: [swift-evolution] [Proposal] Protected Access Level

Brent, I personally was also thinking of the UIGestureRecognizerSubclass example, and I think it’s the best example of ‘protected’ use case, but I think I came to a slightly different position you did. You come to this from the perspective of “can we do something with the same limitations of U

Re: [swift-evolution] [Proposal] Protected Access Level

> My answer is this: There is nothing magical about being a subclass that ought > to grant access to those methods. There is - it's a family member that you let use your summer house. Without the metaphor, here is an example for this being useful: URLConnection subclass may want to update the

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

> On 28 May 2016, at 23:48, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition Clauses” begins now an

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

> On 28 May 2016, at 23:48, Chris Lattner via swift-evolution > wrote: > > >> On May 27, 2016, at 12:11 PM, Joe Groff > > wrote: >> >> Hello Swift community, >> >> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs >> through June 3, 2016. T

Re: [swift-evolution] [Proposal] Protected Access Level

> Unless I'm missing something Brent, your suggestions still wouldn't allow the > developer to provide a public class in a module designed to be subclassed by > clients in another module and access these "private" details, which is a real > problem I'm having in my current project. > > I have a

Re: [swift-evolution] Variadic generics discussion

> On 29 May 2016, at 02:33, Austin Zheng wrote: > >> - I have an argument pack. How would I apply a function taking a single >> argument to each element in the pack? Go via the tuple? > > This is definitely something that needs to be worked out. The C++ pack expansion rules http://en.cpprefe

Re: [swift-evolution] [Proposal] Protected Access Level

I agree - both will need to be addressed in the future to make the language complete. There are some valid points, however, in the blog post - would you allow extensions to access protected variables and potentially expose them to other classes? I.e: /// Class in module A: class View {

Re: [swift-evolution] [Proposal] Protected Access Level

Without wither abstract classes or a protected access modifier, the status quo, that kind of ExceptionThisMethodShouldBeOverridden are really ugly bad code there is no alternative to beyond a religious stop using classes and sub classing... did you not know about your pop saviour ;)? Sent from

Re: [swift-evolution] [Proposal] Protected Access Level

Ditto - I would love to be able to disallow non-subclasses accessing/modifying some variables. Though, I'm not sure what would be the stand on this from the core team - according to Apple's blog they've already considered protected access level: https://developer.apple.com/swift/blog/?id=11 Ch

Re: [swift-evolution] [Pitch] #warning

+1 - this is a useful feature in C-like languages. I'd prefer adding #error as well - you can have a file that depends on the OS features and may want to have a branch of the #if statements ending in #if os(OSX) /// ... #if os(Linux) /// ... #else #error("This OS isn't s

Re: [swift-evolution] Variadic generics discussion

Something that long could probably use a "detailed design" section showing that some consideration was given to how to make it appear in a compiler. > On May 28, 2016, at 10:03 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I put together a draft proposal for