Re: [swift-evolution] Returning nothing

Regards LM (From mobile) > On Jul 21, 2016, at 7:51 PM, Haravikk via swift-evolution > wrote: > > >>> On 21 Jul 2016, at 17:52, Matthew Johnson via swift-evolution >>> wrote: >>> On Jul 21, 2016, at 11:42 AM, Daniel Steinberg via

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

As unfocussed as original Regards (From mobile) > On Jul 22, 2016, at 12:40 AM, Adrian Zubarev via swift-evolution > wrote: > > https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md > > Rename T.Type > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

Regards LM (From mobile) > On Jul 21, 2016, at 4:59 PM, Adrian Zubarev via swift-evolution > wrote: > > Hello Brent, thank you for your feedback on the review process of our > proposal. > > I think this proposal is a huge mess. I don’t understand why the split >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0126: Refactor Metatypes, repurpose T.self and Mirror

said as much privately (just not that colorfully though) to author, trying to hint at a number of problems that limited its usefulness. Regards LM (From mobile) On Jul 21, 2016, at 11:30 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 20, 2016, at 5:18

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Regards (From mobile) > On Jul 21, 2016, at 9:20 AM, Robert Widmann via swift-evolution > wrote: > > > > ~Robert Widmann > > 2016/07/21 0:13、Pyry Jahkola via swift-evolution > のメッセージ: > >> On 21 Jul 2016, at 09:51, Robert

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Regards (From mobile) > On Jul 21, 2016, at 12:38 AM, Robert Widmann wrote: > > As cannot (and should not) hide substructures and can be added later if you > so desire. > > >> On Jul 20, 2016, at 3:36 PM, L. Mihalkovic >> wrote: >> >>

Re: [swift-evolution] [Proposal][Discussion] Qualified Imports

Hiding is not necessary if you import into a pseudo container... It means the ide does not have to keep track of whats here whats not on a per source file basis Import CoreGraphics as cg cg.x Collisions are always avoided and there is only adding imports. Simple. Regards (From mobile)

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

Regards (From mobile) On Jul 20, 2016, at 7:34 PM, John McCall via swift-evolution wrote: >>> On Jul 20, 2016, at 10:13 AM, Károly Lőrentey wrote: >>> On 2016-07-18, at 19:05, John McCall via swift-evolution >>>

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

Regards LM (From mobile) On Jul 20, 2016, at 2:16 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 19, 2016, at 10:50 PM, Chris Lattner via swift-evolution >> wrote: >> >>* What is your evaluation of the proposal? > > I

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

Regards LM (From mobile) > On Jul 20, 2016, at 9:54 AM, Tino Heth via swift-evolution > wrote: > > Hi Peter, > >> Am 20.07.2016 um 00:26 schrieb Peter Livesey via swift-evolution >> : >> >> 1. I don't understand what problem this

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

Regards (From mobile) > On Jul 16, 2016, at 9:17 PM, John McCall via swift-evolution > wrote: > >> On Jul 16, 2016, at 11:48 AM, Xiaodi Wu wrote: >> On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution >>

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

Regards (From mobile) > On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 19 Jul 2016, at 19:37, L. Mihalkovic wrote: >> >> >> >> Regards >> (From mobile) >> >>> On Jul 19, 2016, at 8:19 PM,

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

Regards (From mobile) > On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > >> >> Cocoa currently hides the boilerplate for all of these wonderful constructs >> behind amazingly effective runtime acrobatics.

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Import Foo.* as bar.// has public methodX() and type TypeA Import Foo2.* as baz. // also has public methodX() and type TypeA would be interesting because it entirely avoids collisions when using both together. It also provides some documentation at the point of use, as well as allow the IDE

Re: [swift-evolution] [Proposal] Qualified Imports and Modules

Interesting... mix of c# and swift and others I am not sure it has many chances to see the light: unless they internally manage to cheat and reuse the natural scoping provided by empty enums, the implications on the binary structure of the dylibs are kolossal... and as if this was not enough,

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

Regards (From mobile) > On Jul 18, 2016, at 9:43 PM, Austin Zheng via swift-evolution > wrote: > > >> On Mon, Jul 18, 2016 at 12:28 PM, Johannes Neubauer via swift-evolution >> wrote: >> Dear Xiaodi, >> >> > Am 18.07.2016 um 20:55

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

Regards (From mobile) > On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution > wrote: > > If people were generally happy with having public members of open classes > overridable by default, then we certainly wouldn't need to have a separate > qualifier

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

Regards (From mobile) On Jul 18, 2016, at 7:12 PM, John McCall via swift-evolution wrote: >> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution >> wrote: >> I disagree that an `open` method overridden from a superclass

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

IMHO implementing your proposal would close the door on some of the things you do when building in-memory dbs (T == U -> TRUE for T not related to U), which if swift remains for small apps is not a terrible loss, but may be more of an issue for one day doing big-data with it. Regards (From

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

Regards (From mobile) On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon <br...@architechies.com> wrote: >> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Jul 17, 2016, at 9:14 PM, Garth

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

Regards (From mobile) > On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution > wrote: > > Is there a summary somewhere of the motivation for allowing methods to be > declared non-overridable within open classes? > > I’m not asking about any particular

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

Regards (From mobile) > On Jul 16, 2016, at 9:35 PM, Adrian Zubarev via swift-evolution > wrote: > > Wrong thread ;) If you think it’s ill-prepared than provide some feedback > instead of just watching and waiting to throw negative feedback during review >

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

Regards (From mobile) > On Jul 17, 2016, at 4:24 AM, L. Mihalkovic > wrote: > > > Regards > (From mobile) > >> On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The second

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

Regards (From mobile) > On Jul 16, 2016, at 7:52 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The second review of "SE-0117: Default classes to be non-subclassable > publicly" begins now and runs through July 22. The proposal is

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

To me this is reminicent of what is happening with the T.Type / Type story, where there seems to be a rush to throw a proposal under the cut-off date even if it is ill-prepared, or based on misunderstandinds. Regards (From mobile) > On Jul 16, 2016, at 7:15 PM, Adrian Zubarev via

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

Regards (From mobile) > On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution > wrote: > > My reply didn’t go to the list… my apologies… > > On Jul 11, 2016, at 8:19 PM, Ford Prefect > > wrote: > > People say

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

Regards (From mobile) > On Jul 15, 2016, at 8:26 AM, Chris Lattner via swift-evolution > wrote: > > >>> On Jul 14, 2016, at 10:58 PM, Charles Srstka >>> wrote: >>> >>> On Jul 14, 2016, at 4:39 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

Regards LM (From mobile) > On Jul 13, 2016, at 2:02 PM, Adrian Zubarev via swift-evolution > wrote: > > This isn’t a full proposal (yet). We still can change things. I didn’t > consider everything and can’t to that on my own. Feedback is welcome. > > To answer

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

Regards (From mobile) > On Jul 12, 2016, at 6:22 AM, Josh Parmenter via swift-evolution > wrote: > > My reply didn’t go to the list… my apologies… > > On Jul 11, 2016, at 8:19 PM, Ford Prefect > > wrote: > > People say

Re: [swift-evolution] [Proposal] Allow Static Function Properties to Satisfy Static Function Protocol Requirements

Regards (From mobile) > On Jul 11, 2016, at 8:24 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Sun Jul 10 2016, Jasdev Singh wrote: >> >> Hey Swift Evolution! >> >> Drafted up a small proposal that harmonizes the use of

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

Regards (From mobile) > On Jul 11, 2016, at 9:43 PM, Tony Allevato via swift-evolution > wrote: > >> On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner wrote: >> Hello Swift community, >> >> The review of "SE-0117: Default classes to be

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

Regards (From mobile) > On Jul 11, 2016, at 12:53 PM, Tino Heth <2...@gmx.de> wrote: > > >> You do realize that then itunes store used to (i don't know hese days) for >> many years run on java, despite objc being such a more advanced environment. >> ;-) > well, from my experience, app

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

Regards (From mobile) > On Jul 11, 2016, at 9:39 AM, Tino Heth via swift-evolution > wrote: > > >> With the existence of Swift on the server, dynamically linked, independently >> distributed frameworks will not be an Apple-only issue - this extends beyond >>

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

Regards (From mobile) > On Jul 11, 2016, at 5:00 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Jul 10, 2016, at 9:53 PM, Paul Cantrell via swift-evolution >> wrote: >> >> >>> On Jul 10, 2016, at 8:49 PM, let var go via

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

To share some perspective, I come from working on 200k to 500k LOC systems, with the largest (aside linux kernel drivers) being ~2M loc/20,000 cpp files. I have done my share of objc coding, much of it for my own usage. My interest in swift has to do with finding a scalable solution for client

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

Regards (From mobile) > On Jul 10, 2016, at 7:34 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Jul 10, 2016, at 12:26 PM, Thorsten Seitz wrote: >> >> >>> Am 08.07.2016 um 17:24 schrieb Matthew Johnson

Re: [swift-evolution] [Discussion] Seal `T.Type` into `Type`

It looks like this is touching on a small subset of the not-yet-designed reflection API (still tabled for 4.0?). I am interested to see what balance it strikes between declarations (eg. being able to reflect extensions declarations), types (eg reflecting type conformance), and operations

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

Regards (From mobile) > On Jul 10, 2016, at 11:25 AM, G B via swift-evolution > wrote: > > I feel like there are two totally different discussions happening here. One > is whether Swift needs better interoperability with C++, which it does. > Let’s just assume

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

Regards (From mobile) On Jul 10, 2016, at 12:01 AM, Károly Lőrentey via swift-evolution 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

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

Regards (From mobile) > On Jul 9, 2016, at 7:06 PM, Jean-Daniel Dupas <mail...@xenonium.com> wrote: > > >> Le 9 juil. 2016 à 18:22, L. Mihalkovic via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> >> Regards >>

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

Regards (From mobile) > On Jul 9, 2016, at 4:30 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jul 9, 2016, at 8:39 AM, Andre wrote: >> >> Personally, Im not against sealed by default, but I think there are cases >> where closed

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

Regards (From mobile) > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > John has done a tremendous job

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

Regards (From mobile) > On Jul 7, 2016, at 6:23 PM, Leonardo Pessoa via swift-evolution > wrote: > > Jean, IMO marking every class as subclassable means the creator does > not care for you to design and develop a great library because s/he is > not caring for the

Re: [swift-evolution] [Review] SE-0077 v2: Improved operator declarations

It really looks like the process is showing its limits... with so many people, some with knowledge of compiler imposed limitations, most with a laundry list of their favorite features from other languages, and even a few aspiring at finally having anti-gravity boots into the compiler, it seems

Re: [swift-evolution] Removing Variadic Parameters.

Even vb does that... If you ever want to write a compiler or anything that has to dynamically adjust its behavior (which i would expect most objc devs never do) then it might be useful to not cut all the claws of this tigger. Regards LM (From mobile) > On Jul 6, 2016, at 8:38 PM, Tino Heth via

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

It looks like there are 2 views being discussed Import System : just masks the difference in platform specific names Import Libc : a true attempt at a swift specific view of credible c runtime equivalent The first one would be easy to do now and would alleviate all the mindless #if...#endif we

Re: [swift-evolution] Seriously! Freeze Swift For Two Years After Release 3.0 !

Regards LM (From mobile) > On Jul 6, 2016, at 8:28 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi there > > From the perspective from many active programmers > that use Swift (not objective C anymore) I am not > very happy by having to change >

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

Regards LM (From mobile) > On Jul 6, 2016, at 10:39 PM, Tino Heth via swift-evolution > wrote: > > >> If you have a ParentClass and a SubClass, and the ParentClass is sealed >> while the SubClass is subclassable. What happens? No matter how this >> question is

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

Regards LM (From mobile) > On Jul 6, 2016, at 7:52 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 5, 2016, at 5:54 PM, Kevin Lundberg via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? >> >>

Re: [swift-evolution] [Review] SE-0107: UnsafeRawPointer API (initialize:with:)

Regards (From mobile) > On Jul 3, 2016, at 10:18 AM, Andrew Trick via swift-evolution > wrote: > > >> On Jul 2, 2016, at 8:10 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> I have a pile of naming quibbles; rather than

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

An interesting take on arg label/name, granted this is including destructuring of obj literals (so one level down from the method sig, but which is not without analogy to what could be done to tuples with named fields). The main point of comparison is what the type of f1 and f2 are. This is

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

Ever considered looking at how typescript handles argument names in object literal deconstruction? Regards (From mobile) On Jul 3, 2016, at 10:36 PM, Pyry Jahkola via swift-evolution wrote: >> On 30 Jun 2016, Chris Lattner wrote: >> >> The review of "SE-0111:

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

Regards LM (From mobile) On Jun 30, 2016, at 9:12 AM, John McCall wrote: >> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic >> wrote: >> >> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution >> wrote: >>

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

Regards (From mobile) On Jul 1, 2016, at 6:43 PM, John McCall via swift-evolution wrote: >>> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon >>> wrote: >>> That starts to look an awful lot like a fifth access level just for classes >>> (I

Re: [swift-evolution] [Discussion] Can we make `.Type` Hashable?

This is IMHO a loophole in the type system today: '.Type' being a contextual keyword that is part of no protocol, there is no formal definition for what its return type and what can be done is purely driven by the compiler implementation. I used to have my oen bread of typeId until I ran into

Re: [swift-evolution] [Proposal] Union Type

@core team: should the be added to the list of common rejections for now or does it stand a chance in the next 2 or 3 versions? Regards LM (From mobile) > On Jul 1, 2016, at 11:06 AM, Cao Jiannan via swift-evolution > wrote: > >

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

Regards (From mobile) On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution wrote: >> On Jun 29, 2016, at 12:05 PM, Michael Peternell >> wrote: >> I'm still unhappy about this "sealed by default" proposal. That really looks >>

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

Regards (From mobile) > On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution > wrote: > > How about `public(extensible)` ? > > On 29.06.2016 21:32, John McCall via swift-evolution wrote: >>> On Jun 29, 2016, at 11:16 AM, Michael Peternell via

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Comparing with c++ is interesting... Do you remember that when u look at the implementation, the modifier is on every single method, so that when looking at a single page of code u do not have to go far to be reminded of the signature of what you are modifying... additionally, because the impl

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Regards (From mobile) > On Jun 29, 2016, at 8:39 PM, Adrian Zubarev via swift-evolution > wrote: > > How is this worse? Your argument about scrolling is just ridiculous. > Look you may want to consider your language... did i call the proposal ridiculous? I could

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Regards (From mobile) > On Jun 29, 2016, at 8:16 PM, Adrian Zubarev via swift-evolution > wrote: > > I can’t resist I’ve got a third argument for your ‘scrolling’: Grab a huge > protocol that does not fit on your screen, which assistance do you have to > get its

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

Regards (From mobile) > On Jun 29, 2016, at 7:43 PM, Adrian Zubarev via swift-evolution > wrote: > > Am I understanding your feedback right that you’re in favor of this: > > public class func member1() {} > public class func member2() {} > public class func

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

-1 looks like a kludgy hack. It will force people to have to scroll back to the declaration of a group (with no assistance to find where it is) in order to ascertain the visibility of a given method, while pushing code further to the right for every single method. Couple that with the zealous

Re: [swift-evolution] [Draft] Rationalizing Sequence end-operation names

@brent: i noticed that you have the habit of redacting out the name of the people from your replies. Considering you seem to be the only one, and how much clarity it removes from the dialog, do you think you could perhaps reconsider? Regards LM (From mobile) On Jun 29, 2016, at 12:40 AM, Brent

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Regards LM (From mobile) On Jun 28, 2016, at 6:32 PM, John McCall wrote: >> On Jun 28, 2016, at 9:12 AM, L. Mihalkovic >> wrote: >> >> Question inline >> Regards >> LM >> (From mobile) >> On Jun 28, 2016, at 1:01 AM, John McCall via

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

Regards LM (From mobile) > On Jun 28, 2016, at 8:04 PM, Douglas Gregor via swift-evolution > wrote: > > >> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution >> wrote: >> >> Hey, all. An engineer at Apple noticed the

Re: [swift-evolution] Setter methods for vars

Regards (From mobile) > On Jun 29, 2016, at 1:11 AM, Michael Peternell via swift-evolution > wrote: > > Really?? Or we just have #set and #get and no lenses, and it's done for Swift > 3? > > I never heard of lenses (Google does not help here). Was this serious or

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Question inline Regards LM (From mobile) On Jun 28, 2016, at 1:01 AM, John McCall via swift-evolution wrote: >> On Jun 25, 2016, at 10:57 AM, Anton Zhilin via swift-evolution >> wrote: >> I replaced `precedencegroup` with `precedence` and

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

>>>> On Jun 28, 2016, at 7:55 AM, Sean Heber <s...@fifthace.com> wrote: >>>> >>>>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>&

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

; >>>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >>>> <swift-evolution@swift

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

Regards LM (From mobile) > On Jun 28, 2016, at 4:52 PM, Mark Lacey <mark.la...@apple.com> wrote: > > >> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> -1 for the fact that if

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

Regards LM (From mobile) > On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution > wrote: > > Anton Zhilin: That is one of the points if I’m not mistaken. Sealed > means that with whole-module-optimization the compiler can optimise > more things as it

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:25 AM, Dave Abrahams wrote: > > >> on Mon Jun 27 2016, "L. Mihalkovic" wrote: >> >> Regards >> (From mobile) >> >>> On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: >>> >>> >>> on Fri Jun 24

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards LM (From mobile) > On Jun 28, 2016, at 12:18 AM, Andrew Trick wrote: > > >>> On Jun 27, 2016, at 1:52 PM, L. Mihalkovic >>> wrote: >>> >>> think you mean T.Type, not T.self, because this looks like a declaration. >>> >>> To

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

-1 for the fact that if all devs can write working code, fewer can do it in a clear structured fashion that is well designed for extensibility. A couple months ago I even ran into difficulties when trying to extend AlamoFire because some things had not been designed as cleanly as they could

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

Regards (From mobile) > On Jun 27, 2016, at 11:59 PM, Adrian Zubarev via swift-evolution > wrote: > > “The access modifier of an extension sets the default modifier of its members > which has no modifier applied to them.” I get it now.. "which do not have their

Re: [swift-evolution] [Draft] UnsafeRawPointer API

Regards (From mobile) > On Jun 27, 2016, at 8:39 AM, Dave Abrahams wrote: > > > on Fri Jun 24 2016, Andrew Trick wrote: > >>> On Jun 24, 2016, at 11:22 AM, Andrew Trick via swift-evolution >>> wrote: >>> On Jun 24, 2016, at 11:17 AM,

Re: [swift-evolution] An upcoming proposal for simplifying leak free, safe closures.

Regards (From mobile) > On Jun 27, 2016, at 10:18 PM, Dennis Lysenko via swift-evolution > wrote: > > My 2c: > > This proposal is made more appealing to me because it is not simply a > 'beginners will get confused' issue. > > I have written tens of thousands of

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

"The access modifier of an extension sets the default modifier of its members which has no modifier applied to them." I cannot understand the sentence, or the following: "If there the extension has no access modifier, then the default modifier of its members which has no explicit modifier will

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

As i said, already deeply regretted mentioning P|Q as on closer examination of a well known precedent it is very realistic to have P only. Apologize again for not doing the due dilligence before pressing send. (From mobile) > On Jun 27, 2016, at 7:04 PM, Austin Zheng

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

Inline Regards LM (From mobile) > On Jun 27, 2016, at 6:48 PM, Joe Groff wrote: > > >> On Jun 25, 2016, at 12:00 AM, L. Mihalkovic >> wrote: >> >> Inline >> Regards >> (From mobile) >> >>> On Jun 25, 2016, at 1:00 AM, Joe Groff via

Re: [swift-evolution] Revisiting SE-0041 Names

Regards LM (From mobile) > On Jun 27, 2016, at 4:45 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 27, 2016, at 9:29 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 22 2016, Matthew Johnson

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

There was an exchange in the past on how extensions are very different from swift nominal/structural types, and Doug even shared how adding scoping to extensions is not a trivial task by a long shot. In this context, talking about unifying modifier behaviors does not make much sense to me. I am

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

Regards (From mobile) > On Jun 25, 2016, at 8:48 PM, Thorsten Seitz wrote: > > >> Am 25.06.2016 um 19:09 schrieb L. Mihalkovic : >> >> >> >> Regards >> (From mobile) >> >>> On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Don't you think that for no other reason than completeness it would make sense to document the metacircular definition I suggested? > On Jun 25, 2016, at 7:57 PM, Anton Zhilin via swift-evolution > wrote: > > I replaced `precedencegroup` with `precedence` and added

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

Regards (From mobile) > On Jun 25, 2016, at 6:34 PM, Thorsten Seitz via swift-evolution > wrote: > > Sorry for the late reply — I had hoped to be able to think more deeply about > various points, > but I’m going to delay that instead of delaying the reply even

Re: [swift-evolution] [Pitch] Remove type inference for associated types

Sometimes I get the sense that the pleasure of discussing takes precedence over the goal it serves, namely to create a language that will be the most attractive it can be within a given complexity budget (meaning a balance between the immediate reward of shiny new things and the long term

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

> On Jun 25, 2016, at 9:00 AM, L. Mihalkovic > wrote: > > Inline > Regards > (From mobile) > >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via

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

Inline Regards (From mobile) > On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution > wrote: > > >> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution >> wrote: >> >> [Proposal: >>

Re: [swift-evolution] [Draft] UnsafeRawPointer API

> On Jun 24, 2016, at 7:43 PM, Andrew Trick wrote: > > >> On Jun 23, 2016, at 10:10 PM, L. Mihalkovic >> wrote: >> >> Very cool... >> >> Couple thoughts >> >> UnsafeMutableRawPointer: >> func store(, WITH: T) >> does not flow very well >>

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

t 2:47 PM, Anton Zhilin via swift-evolution > <swift-evolution@swift.org> wrote: > > L. Mihalkovic via swift-evolution <swift-evolution@...> writes: > >>> Could you please explain what you mean by "meta-circular syntax for > the >>> precedenc

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

> On Jun 24, 2016, at 6:04 PM, Jordan Rose wrote: > > >> On Jun 23, 2016, at 22:20, L. Mihalkovic >> wrote: >> >> >> Regards >> LM >> (From mobile) >> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution >>

Re: [swift-evolution] [Review] SE-0102: Remove @noreturn attribute and introduce an empty NoReturn type

Although i understand the intention, there are existing designs in other languages offering proven better alternatives. So i would not leave thinking that a compelling case for 'Never' has been made. > On Jun 24, 2016, at 6:01 PM, Anton Zhilin via swift-evolution >

Re: [swift-evolution] Fw: Re: [Proposal Draft] Literal Syntax Protocols

I find these 'stay-off-my-property' _ rather sub-par in a modern language (everything was different for c 40years ago). I find it rather sad to think that we r about to commit to using that pattern for another 30 years. If the demark between stdlib and compiler was cleaned up, it would even

[swift-evolution] Fwd: [Returned for revision] SE-0077: Improved operator declarations

(From mobile) >> On Jun 24, 2016, at 2:47 PM, Anton Zhilin via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> L. Mihalkovic via swift-evolution <swift-evolution@...> writes: >> >>>> Could you please explain what you mean by &

Re: [swift-evolution] Shorthand unwrap proposal

Regards LM (From mobile) > On Jun 24, 2016, at 2:50 PM, Charlie Monroe via swift-evolution > wrote: > > Yes, this is a bit different. There was a discussion about a month ago > (http://thread.gmane.org/gmane.comp.lang.swift.evolution/17142) which had a > few good

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

> On Jun 24, 2016, at 11:25 AM, Patrick Smith via swift-evolution > wrote: > > I’ve never quite understood why people are so strict about keeping to this? especially considering how many who do have never seen a vt100 terminal > >> On 24 Jun 2016, at 4:04 PM,

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

Regards LM (From mobile) > On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md > ] > > I’ve gone on record before as against this syntax,

Re: [swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

Quick (semi) related question: any particular reason for .Type to be a contextual kwd rather than defined on a protocol? (No concrete def for metatypes?) Regards LM (From mobile) > On Jun 23, 2016, at 11:02 PM, Andrew Trick via swift-evolution > wrote: > > >>> On

Re: [swift-evolution] [Returned for revision] SE-0077: Improved operator declarations

Inline Regards (From mobile) > On Jun 23, 2016, at 10:13 PM, Anton Zhilin via swift-evolution > <swift-evolution@swift.org> wrote: > > L. Mihalkovic via swift-evolution <swift-evolution@...> writes: > >> Has a meta-circular syntax been considered for the prec

  1   2   3   4   >