Re: [swift-evolution] [Draft Proposal] Require `final` on protocol extension members

I agree with you, if we tackle this and we should then we should aim to the right solution if it is reachable. I know I am in the minority and it is partially off topic here, but I do feel that default method implementations are something that might be put to good use, but it is best to try to

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

I think we want to leave throws and rethrows at the method signature level and to mean that we want to throw an actual exception so I would not reuse it this way as it would be confusing. Sent from my iPhone > On 29 Dec 2015, at 14:24, Amir Michail wrote: > > >> On Dec 28,

Re: [swift-evolution] [Proposal] Swift 2.2: #if swift language version

+1 from me as well, supporting conditional compilation when the two versions of foundation differ and may differ for the foreseeable future seems a must on this end. Sent from my iPhone > On 3 Jan 2016, at 10:12, Drew Crawford via swift-evolution > wrote: > >> If

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

> That said, personally, my feeling is that the momentum here in the broad > family of C languages (including things like Java) is very strong, and that > diverging from that would be extremely problematic. I don’t see any “active" > problems with our current names. If this is a matter of

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

Hello Chris, When dealing with floating point values, wouldn't it be in our best interest to always be very specific about the accuracy of the floating point type variables we use regardless of the device it runs on? This is the biggest problem I had with CGFloat: while it is nice at first to

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On 3 Jan 2016, at 18:21, Matthew Johnson via swift-evolution > wrote: > > >> On Jan 3, 2016, at 12:12 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> On Jan 2, 2016, at 2:23 PM, Tyler Cloutier

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

Loved the insight about the positive net effect on language symmetry, quite important yet sometimes the unsung hero of such discussions :). Sent from my iPhone > On 6 Jun 2016, at 08:26, David Hart via swift-evolution > wrote: > > >>• What is your evaluation

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

I think sometimes the community in this mailing list loses sight on the fact that coding is a creative endeavour much similar to architectural design or painting. There may be math and well researched and structured ideas in place, but it requires creativity too. Trying to force a strict one

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

If the litmus test is whether using something can go awry and can go awry at runtime then you are going to have to chop off a lot of parts of most languages. Also, some programmers do not mind not being protected from themselves and trade that for extra freedom... which is not a bad thing in

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

I was not advocating the lack of constraints, programmers like all other artists (and engineers, which are artists too ;)), but that the beauty is the moderation of the two extremes :). ... and that architects leave the problems you are talking about to the structural engineer :P. Gravity is a

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

It would not be like going back to Windows 95... and I did not mention the infamous OSR3 release to make that harsh of a point :P... On Fri, Jun 10, 2016 at 8:09 PM, Xiaodi Wu wrote: > On Fri, Jun 10, 2016 at 2:06 PM, Goffredo Marocchi > wrote: > >> I

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

Agreed! Sent from my iPhone > On 28 May 2016, at 08:10, L. Mihalkovic via swift-evolution > wrote: > > >> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution >> wrote: >> >> On May 27, 2016, at 6:26 PM, Brent

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

This I would not cry about. In other languages they are more of a source of pain than anything else. Sent from my iPhone > On 28 May 2016, at 09:10, David Hart via swift-evolution > wrote: > > Yet another alternative: would it be possible to disallow commas as

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

Hello Dave, Sent from my iPhone > On 13 Jun 2016, at 03:04, Dave Abrahams via swift-evolution > wrote: > > > on Fri Jun 10 2016, Thorsten Seitz wrote: > >>> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >>> : >>>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

I would say we need a separate meeting where we propose to add them and discuss why we would want them in Swift :). Sent from my iPhone > On 13 Jun 2016, at 16:26, Erica Sadun via swift-evolution > wrote: > > >> On Jun 13, 2016, at 9:23 AM, let var go via

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

Great news :) Sent from my iPhone > On 26 May 2016, at 06:53, Austin Zheng via swift-evolution > wrote: > > The inimitable Joe Groff provided me with an outline as to how the design > could be improved. I've taken the liberty of rewriting parts of the proposal >

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

Hello David, Could you elaborate on this more? Seeing the possibilities of FSM's in Swift using its powerful enum and case pattern matching was one of the moments in which Swift started increasing its allure factor ;). Part 1 (background and theory):

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,

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

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

An argument could be made that the '\' character is used to escape and when you are doing string interpolation/printing you are clearly doing an operation more similar to bash's use of '$' to extract the value of a variable than escaping. The need to logically separate escaping from parameter

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

Sorry, but can you explain why the character used to escape strings is also the best choice to do Variable value extraction/String interpolation? They are two different concepts. Sent from my iPhone On 22 Jun 2016, at 09:28, Charlie Monroe via swift-evolution

Re: [swift-evolution] Thoughts on replacing \() with $() or some other symbol

wrote: > > >> On 22 Jun 2016, at 09:39, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Sorry, but can you explain why the character used to escape strings is >> also the best choice to do Variable value extrac

Re: [swift-evolution] [META] Re: Mailman?

You speak and I hear custom Google Wave setup still... ;) http://incubator.apache.org/wave/ Sent from my iPhone > On 15 Mar 2016, at 16:52, Joe Groff via swift-evolution > wrote: > > >> On Mar 15, 2016, at 3:27 AM, Adrian Kashivskyy >>

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

How about - “public” -> symbol visible outside the current module. - “package or module” -> symbol visible within the current module. - internal -> symbol visible within the current file. - “private” -> symbol visible within the current declaration (class, extension, etc). ? Sent from my

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I agree with you Tino that we should not stop here, but I would break it down in smaller proposals that had the biggest breakage in the language but still could all fit into Swift 3. It is one of the last chances of being allowed to break source and ABI compatibility and we ought to make it

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Great summary, but I would still use new keywords rather than adding modifiers to private itself. public module file/ sourceFile /pick a better word :) private Sent from my iPhone > On 16 Mar 2016, at 06:49, Patrick Pijnappel via swift-evolution > wrote: > > Ok to

Re: [swift-evolution] [Proposal] Factory Initializers

I thought this already went in review somehow, sorry a +1 from me as well. [[iOS messageWithData:ideas] broadcast] > On 10 Apr 2016, at 19:14, Radosław Pietruszewski via swift-evolution > wrote: > > Nice! > > I must admit, my first reaction to this proposal was

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Proposal sounds nice, but shouldn't it go hand in hand with the review of dispatching rules for protocol extensions (i.e.: dynamic dispatch by default unless overridden by a user declaration/annotation or when the compiler is sure no side effects will occur... ProtocolA and

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I think that supercalifragilisticexpialidocious may benefit from lowerCamelCasing ;). [[iOS messageWithContent:webContent] broadcast] > On 24 Mar 2016, at 11:02, Dany St-Amant via swift-evolution > wrote: > > >> Le 24 mars 2016 à 01:13, Chris Lattner via

Re: [swift-evolution] Rewrite imported C function signatures

+1 for me too, sounds like a very useful syntax with a not incredibly huge cost. [[iOS messageWithContent:webContent] broadcast] > On 27 Mar 2016, at 09:31, Carlos Rodríguez Domínguez via swift-evolution > wrote: > > That’s a really good syntax. Maybe the new

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

Agreed, seems like a good way to go. [[iOS messageWithContent:webContent] broadcast] > On 24 Mar 2016, at 07:04, David Hart via swift-evolution > wrote: > > I like it very much. > >> On 24 Mar 2016, at 06:13, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Revisiting 0004 etc. - Swift deprecations

It would be very interesting to see more examples dynamic loop conditions and dynamic loop increments using the Swifter for in loop with strides... without while :). [[iOS messageWithData:ideas] broadcast] > On 3 Apr 2016, at 09:19, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

Very good points Dietmar, but there is one more bit about default implementations in extensions that makes it worse to use than the old Objective-C model... the complex dispatch rules that can make the executed method type dependent and not instance dependent. We really need dynamic dispatch

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Hello Dave, > That makes these people suspicious of language features that could > threaten to make classes “second-class citizens.” ...and that is unfortunate when emotions and resistance to positive change worsen the discussion, but if you take a look at discussion related to abstract

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I still think that the type of the reference governs which code runs feels so vestigial of a part of C++ I always disliked (default if you are not using the virtual keyword). Especially dealing with protocols that have generally always be interpreted to be abstract API contracts. I would say

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[[iOS messageWithData:ideas] broadcast] > On 26 Apr 2016, at 07:28, David Owens II via swift-evolution > wrote: > > What is your evaluation of the proposal? > I reluctantly agree with the proposal with the following caveat: I do not > agree with the rationale to

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Agreed, this is a topic that needs to be properly solved. Sent from my iPhone > On 20 May 2016, at 05:34, Krystof Vasa via swift-evolution > wrote: > > From the rejection rationale: > >> * Individuals or teams that feel that explicit “self.” is beneficial for >>

Re: [swift-evolution] Proposal SE-0009 Reconsideration

The code you pasted really ought to print a warning out (allowing variable shadowing without even a warning can lead to annoying bugs), a generation of Swift developers will be trained by relying on the Swift compiler to make their code automagically safe and this is another one of those Not

Re: [swift-evolution] Proposal SE-0009 Reconsideration

In addition to what has already been posted: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future https://medium.com/ios-os-x-development/swift-protocol-extension-method-dispatch-6a6bf270ba94#.14j0qq1i3 (even more complete summary of previous research in this issue)

Re: [swift-evolution] Static Dispatch Pitfalls

Sent from my iPhone > On 22 May 2016, at 18:36, L. Mihalkovic via swift-evolution > wrote: > > >> On May 22, 2016, at 5:31 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On May 22, 2016, at 8:39 AM, L. Mihalkovic

Re: [swift-evolution] Static Dispatch Pitfalls

Sent from my iPhone > On 22 May 2016, at 07:03, Vladimir.S via swift-evolution > wrote: > > I support *at least* to introduce such a special marker for method declared > *only* in protocol extension (no declaration for it in protocol itself) to > make it clear that

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Is the status quo in this honey moon phase better? Sent from my iPhone > On 19 May 2016, at 19:12, Sean Heber via swift-evolution > wrote: > > I think it is too easy to just add warnings for warts and call it a day. > These problems, IMO, should be addressed

Re: [swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

Associated object based tricks may be used in the meantime, KVO on objects with an uncertain duration was always problematic. Sent from my iPhone > On 11 May 2016, at 14:30, Patrick Smith via swift-evolution > wrote: > > I remember reading that Swift’s weak

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

Pereira via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On 16 May 2016, at 18:38, Goffredo Marocchi via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> Quite sad we could not get into ABI stabilit

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

Thanks Brent, this one is quite a keeper :). Concise and very friendly way of explaining RawRepresentable. Sent from my iPhone On 17 May 2016, at 21:05, Brent Royal-Gordon via swift-evolution wrote: >> On the other hand: What's the point of "raw-value enums"? Are

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-0088: Modernize libdispatch for Swift 3 naming conventions

Hey Jacob, I agree with you that there are some unanswered questions and areas we would need some more polish on, but libdispatch was a bit unwieldy in Objective-C already and when used as is in Swift code it looks to be even less user friendly and not because it has to, but because of a lack

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

Sent from my iPhone On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution wrote: >> There we are. I read the declaration of the function from beginning to end >> and gradually formed a rough understanding of it without needing to change >> my expectations

Re: [swift-evolution] [Pitch] Including yes/no in stdlib as aliases for true/false

I think the descriptive/natural language aspect of Objective-C and Cocoa was and is a strength that should be kept in Swift too. It may be perceived as a pragmatist attempt to simplify the language somewhat or make it appear friendlier, but it is not a bad thing in and of itself. [[iOS

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

+1 it improves readability a lot and thus should be encouraged. [[iOS messageWithData:ideas] broadcast] > On 6 May 2016, at 07:57, Thorsten Seitz via swift-evolution > wrote: > > +1 > > I do like the syntax suggested by Dennis. Making use of Swift's ability to >

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Let's build strings the same way we log String("\(authorOfAutoLayoutMasterBook) could you please show \(canICountHowMany) times more love to \(ToolThatBuildsInterfaces) :)") ^_^ ? [[iOS messageWithData:ideas] broadcast] > On 18 Apr 2016, at 20:06, Erica Sadun via swift-evolution >

Re: [swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types

Don't get me started on the case insensitive file system in OS X, some programs still do not work right without it and it is a cause of errors that just piss me off... especially when you share data outside of the happy case insensitive castle :/. [[iOS messageWithData:ideas] broadcast] > On

Re: [swift-evolution] Swift 3.1 vs Swift 4

Sly sly manager you are, but I thought popular culture taught us you used automated schnapps IV's for peak productivity ;). http://xkcd.com/323/ Sent from my iPhone > On 25 Jul 2016, at 22:33, Chris Lattner via swift-evolution > wrote: > > >> On Jul 25, 2016,

Re: [swift-evolution] adding Obj-C syntax to Swift?

I do not think it is likely, but it would be somewhat interesting if one day macOS and IOS were the only two platform using the least diffused/niche dialect of Swift while on Linux, Android, and Windows people were all using a dialect of Swift which became the de facto standard in the case

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

> After all… you clearly don’t know about your current state, so how can you > know how to correctly recover from it? This a bit of a stretch, it is often the case but not a necessary conclusion. Both C++ and Java have a model where it is not uncommon to recover from exceptions instead of

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

olved in code but I don't think it is necessary. > > L > > > On 22 July 2016 at 14:08, Goffredo Marocchi via swift-evolution > <swift-evolution@swift.org> wrote: >> I think that the current approach marks a regression in declarative >> expressiveness as the notion of

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

I think that the current approach marks a regression in declarative expressiveness as the notion of extending a class over implementing a protocol is blurred while the concepts are IMHO not the same (the latter is about behaviour conformance not a is a relationship): Class/struct B :

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

ocol is essentially useless even if > you're a reader. What could you possibly do with this information? > >> L >> >> >> On 22 July 2016 at 14:08, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> > I think that the cu

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

now what P is, no clarification >>> is necessary; on the other hand, if you don't know anything else about P, >>> knowing whether P is a class or protocol is essentially useless even if >>> you're a reader. What could you possibly do with this information? >>> >

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Sent from my iPhone > On 23 Jul 2016, at 06:00, Wang LiMing via swift-evolution > wrote: > > > There’s two case : >1. Bug from customer’s code >2. Bug from library/Framwork’s code > > If we fix the case 1(forbidden subclass/overriding), means the >

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

So no final Swift 3.0 for Xcode 8 / iOS launch (late 2016 speaks like late November or December 2016 while iOS 10 feels like September timeframe). Sent from my iPhone > On 31 Jul 2016, at 05:46, Douglas Gregor via swift-evolution > wrote: > > >> On Jul 30, 2016,

Re: [swift-evolution] [Pitch] separate syntax of class inheritance and protocol conformance

Sent from my iPhone > On 31 Jul 2016, at 21:19, Sean Alling via swift-evolution > wrote: > > I disagree with this suggestion. Both a protocol conformance & class > inheritance define behavior conformance. If anything the protocol is more > explicitly shown

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

+Swift Evolution By the way, I was genuine when I said thank you because reading how Rust evolved in those two aspects is very insightful. On Thu, Aug 11, 2016 at 6:54 PM, Goffredo Marocchi wrote: > Hello Kevin, > > I may be wrong in my equating support for fibers to green

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Thanks Kevin, I think they have accepted that they do not need to enter every segment of computing so the extra performance they could get on some devices is not worth the risk and the complexity it brings. Not everyone is trying to cram complex 3D experiences at 60-90+ FPS on a console like

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

Thanks for the concise and clear review of green threads :). I can understand the concerns of runtime implementation when the runtime of the language is replacing the kernel scheduler. Sent from my iPhone > On 11 Aug 2016, at 19:09, Kevin Ballard wrote: > > AIUI, fibers are

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

LLVM is getting actual coroutine support, do you think it is going to help Swift started in this direction? Sent from my iPhone > On 11 Aug 2016, at 22:17, Slava Pestov <spes...@apple.com> wrote: > > >> On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution

Re: [swift-evolution] Improved value and move semantics

While I understand both your position and Joe's one, I think that it is good if in the Swift community at large, outside of this mailing list itself, more thought was given also to the side effects / losses in moving everything over to value types over references (one could have said with

Re: [swift-evolution] [Proposal] Sealed classes by default

You are not familiar with us Italians and our love for (hopefully reasonable) arguing I see ;). I commit to and accept the decision taken, but it remains a decision I disagree with and something that will probably birth a painful fork once say Android and/or other big corporations moved to

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

Sent from my iPhone > On 14 Jul 2016, at 04:58, Chris Lattner <clatt...@apple.com> wrote: > > >> On Jul 9, 2016, at 1:56 AM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> Sent from my iPhone >>

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 19 Jul 2016, at 15:36, Andre via swift-evolution > wrote: > > Agreed, and I'm ironically reminded of the old days (as a barely conscious > human being) where everyone was poopooing objective-c [...], interface > builder is weird, oh and

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > > Cocoa currently hides the boilerplate for all of these wonderful constructs > behind amazingly effective runtime acrobatics. This fits perfectly into > Objective-C, and it also works very well in Swift. But such features could be > in better harmony with Swift's

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

mobile) >> >>> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> Sent from my iPhone >>> >>>> >>>> Cocoa currently hides the boilerplate

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 19 Jul 2016, at 19:37, L. Mihalkovic <laurent.mihalko...@gmail.com> wrote: > > > > Regards > (From mobile) > >> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.

Re: [swift-evolution] Disallow local parameter names in protocols

Sent from my iPhone > On 19 Jul 2016, at 23:30, Dave Abrahams via swift-evolution > wrote: > > >> on Tue Jul 19 2016, James Froggatt wrote: >> >> Made a draft proposal to start this discussion, and help define the >> problem. I'm not

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

gt;> Sent from my iPhone >> >>> On 19 Jul 2016, at 19:37, L. Mihalkovic <laurent.mihalko...@gmail.com> >>> wrote: >>> >>> >>> >>> Regards >>> (From mobile) >>> >>>> On Jul 19, 2016, at 8:19 P

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

Sent from my iPhone > On 20 Jul 2016, at 06:50, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0122: Use colons for subscript declarations " begins now > and runs through July 24. The proposal is available here: > >

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

So either open by default and sealed optionally or sealed by default and no escape hatch? On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Proposal: Extend Optional Chaining to Function, Initializer, and Subscript Parameters

I did not mind sending messages to nil being essentially a NoOp so calling map on an optional and have the function only execute if the value included inside the optional is not nil is kind of reminding of that ;). Although it is a lot wordier and not really in line with how we force people to

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

Hello Xiaodi, > A general principle of Swift, recently strengthened by proposals such as > SE-0117, has been that public API commitments should require explicit opt-in. > Given the different behavior of classes and structs, the fact that extensions > allow public methods to be declared without

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I disagree that a stable for over 30 years of every OOP language that I know is equivalent to lack of care for good library design, but if we want to push value types by making working with classes harder so be it :P. Seriously though > Mine is the opinion of a library-maker, > yours of the

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Leonardo, how is defaulting to final/sealed helping you write better libraries than having a final keyword for what you need to close instead? Sent from my iPhone On 6 Jul 2016, at 16:48, Leonardo Pessoa via swift-evolution wrote: >> The review of "SE-0117: Default

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution > wrote: > > In the era of increased open sourcing, easy forking, and more > community-driven development, this concern is less severe than it used to be. > I rarely use any

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others. > On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution >

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

ing all the code-breaking changed and > Brent's counterproposal is additive, it leaves at least a year-long period of > not having the parameter labels in closures. > > I agree with the change, I don't agree with the timing where it doesn't have > a replacement yet. > >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution > wrote: > > Of course, Swift doesn’t allow this. If someone outside of the module > subclasses ModelBase, there’s no way for them to provide the > dynamically-dispatched

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

t;> On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I still say that this is the case where we do take a stand and do ask for >> this proposal to be blocked and re-analised, I cannot believe that we are

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Sent from my iPhone > On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution > wrote: > > Even in Java, it is a bad idea to leave classes subclassable; but having to > remember to add final is a chore. I still think it is worth doing that chore. The fact of

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

;> proposal, I'm sure that writing and submitting a counterproposal will be a >> far more effective way of accomplishing that goal. >> >> >> If this change simplified the compiler a lot it is a positive, but I >> think there is a void that need to be addressed as I thin

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

ed by default brings more positives than >> negatives… >> >> Thanks in advance. >> >> Andre >> >> >> > 2016/07/09 21:36、Matthew Johnson via swift-evolution >> > <swift-evolution@swift.org> のメール： >> > >> > >

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> > > I am quite sure that they are discussing this internally :) Also, its > weekend, let people get some rest! > > >> On 09 Jul 2016, at 10:56, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> Sent from my iPh

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

; wrote: > > > > Sent from my iPad > >> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> Sent from my iPhone >> >>> On 8 Jul 2016, at 15:09, Károly Lőrentey via

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Reposting Károl reply on this list. On Sat, Jul 9, 2016 at 11:01 PM, Károly Lőrentey wrote: > > > On 2016. Jul 9., at 22:55, Goffredo Marocchi wrote: > > > > Why have they not "fixed" this issue with Java 6/7/8 if it is bad to > have the current setup by

Re: [swift-evolution] Swift-based Metal Shading Language

I disagree. While it sounds nice to have a unified syntax working on C++ compatibility/interaction is still quite key because of the mountains of legacy and new code still written everyday in it. Also, I think that the right language for the right domain and being able to glue them together is

Re: [swift-evolution] Swift-based Metal Shading Language

Sent from my iPhone On 10 Jul 2016, at 08:50, Georgios Moschovitis wrote: >> working on C++ compatibility/interaction is still quite key because of the >> mountains of legacy and new code still written everyday in it. > > Totally agree, but C++

Re: [swift-evolution] Swift-based Metal Shading Language

Sent from my iPhone On 10 Jul 2016, at 08:50, Georgios Moschovitis wrote: >> working on C++ compatibility/interaction is still quite key because of the >> mountains of legacy and new code still written everyday in it. > > Totally agree, but C++

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

Is it more unreasonable to ask developers to seal their modules or users to unseal them? I would say Apple or third parties shipping frameworks could be asked to think about subclass ability before shipping their commercial library. Sent from my iPhone > On 11 Jul 2016, at 07:36, Rod Brown via

Re: [swift-evolution] [Review] SE-0117: Default classes to benon-subclassable publicly

Sent from my iPhone > On 11 Jul 2016, at 09:42, Tino Heth via swift-evolution > wrote: > > >> The justification for this proposal is all about supporting the people who >> are working to design library APIs right, and about maintaining consistency >> with the

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

abel >> } >> >> func bar(something: Bool) { } >> >> foo(bar) // okay: labels not considered >> >> The proposal should be updated accordingly so it’s clear for future readers. >> PR welcome ;) >> >> - Doug >> >>

  1   2   3   >