Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 11:54 PM, Xiaodi Wu wrote: > > I disagree. First, in both cases there's an A and a B. The two scenarios we > are comparing are "if condition continue, else break" and "if condition > continue, else fallthrough". Both break and fallthrough are equally

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I disagree. First, in both cases there's an A and a B. The two scenarios we are comparing are "if condition continue, else break" and "if condition continue, else fallthrough". Both break and fallthrough are equally control transfer experiments. Both of these scenarios add complexity for reasoning

Re: [swift-evolution] [Pitch] Extending Swift Literals

On Jul 10, 2016, at 11:43 PM, Zach Waldowski via swift-evolution wrote: > > I share the concern with others about the usefulness of these, but I also > like your note about standardizing syntax, and really like that these merge > together all the different syntaxes

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

> On Jul 10, 2016, at 10:30 PM, David Owens II wrote: >>> >>> I wish the core team or the author of the proposal came to this thread and >>> engaged again with the community. >> >> I'm not inclined to spend time engaging with people who couldn't be bothered >> to give

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 11:42 PM, Xiaodi Wu wrote: > > Right. Both seem equally reasonable alternatives if a condition isn't > fulfilled where I'd like to continue pattern matching. Why do you say one of > these would be fair to disallow? I'm saying pick behavior A or

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

> It is *not* the case with a framework. Dynamically linked frameworks can be > changed without the app even being changed. Imagine if Apple changed UIKit > and make UINavigationController final retroactively. Your argument is true, and you choose a good example — but it's actually the only

Re: [swift-evolution] [Pitch] Extending Swift Literals

I share the concern with others about the usefulness of these, but I also like your note about standardizing syntax, and really like that these merge together all the different syntaxes for literals we've seen. To that end, I'd like to modestly suggest that #literal.foo (as already written in

Re: [swift-evolution] Change subscripts to use colons

> On Jul 10, 2016, at 5:18 PM, James Froggatt via swift-evolution > wrote: > > Currently, the signature is: > subscript(_ example: Int) -> Element { >get { … } >set { … } > } > > The alternative, using a colon, would be: > subscript(_ example: Int) : Element

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

Because one says "consider the next case" and the other says "do not consider the next case" > On Jul 10, 2016, at 11:03 PM, Xiaodi Wu wrote: > > I know how it works. Why would you say that it's reasonable to prohibit > fallthrough when continue is used? The difference

Re: [swift-evolution] [Pitch] Extending Swift Literals

Not completely sold on this one. First, the literal part is already pretty much implied, and I'd prefer dropping it as it feels too "heavyweight". The other, more serious issue was already partially touched upon by Xiaodi, that a lot of these are basically String representations. The Bezier

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

> On Jul 9, 2016, at 9:08 AM, Austin Zheng via swift-evolution > wrote: > >> On 9 Jul 2016, at 00:53, Jon Shier > > wrote: >> >>> While I can see why removing the labels from the type system would be a >>> good idea, I

Re: [swift-evolution] Change subscripts to use colons

+1, seems right to me. The original email wasn't clear to me, but this example is. FWIW, as a user of the language I'd hope that throwing subscript getters/setters would be written "set throws { ... }" and/or "set(newValue) throws { ... }" rather than "throwing set { ... }", for consistency with

Re: [swift-evolution] Change subscripts to use colons

+1 as well. It always feels a little weird to be writing a setter inside something that says it returns what should be the argument. On Mon, Jul 11, 2016 at 00:05 Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote: > Good point. A subscript basically a parameterized

Re: [swift-evolution] Change subscripts to use colons

Good point. A subscript basically a parameterized property, not a function. I'm in favor. On Mon, Jul 11, 2016 at 9:18 AM, James Froggatt via swift-evolution < swift-evolution@swift.org> wrote: > Currently, the signature is: > subscript(_ example: Int) -> Element { > get { … } > set { …

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

I know how it works. Why would you say that it's reasonable to prohibit fallthrough when continue is used? The difference between it and break is that Swift chooses the latter to be implied, and obviously we cannot prohibit break. On Sun, Jul 10, 2016 at 23:51 Erica Sadun

Re: [swift-evolution] [Pitch] Extending Swift Literals

Well, in my book, a thing without a representation isn't really a 'literal', which to me implies some degree of WYSIWYG :) On Sun, Jul 10, 2016 at 23:56 Erica Sadun wrote: > > > On Jul 10, 2016, at 10:30 PM, Xiaodi Wu wrote: > > > >

Re: [swift-evolution] [Pitch] Extending Swift Literals

> On Jul 10, 2016, at 10:30 PM, Xiaodi Wu wrote: > > Questions/comments-- > > What's your use case for these? > > For proposed literals like `point`, I'm having trouble visualizing how that > could be literally represented. Since the difference between one point and >

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 10:34 PM, Xiaodi Wu wrote: > > > > On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun > wrote: >> On Jul 10, 2016, at 10:16 PM, Xiaodi Wu > > wrote:

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

On Sun, Jul 10, 2016 at 10:38 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > (This is my second response to this proposal. The previous message

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

On Sun, Jul 10, 2016 at 11:21 PM, Erica Sadun wrote: > On Jul 10, 2016, at 10:16 PM, Xiaodi Wu wrote: > Given patterns A, B, C, and D, suppose a value x matches A, C, and D, > whereas another value y matches B and D, and a third value matches B and >

Re: [swift-evolution] [Pitch] Extending Swift Literals

Questions/comments-- What's your use case for these? For proposed literals like `point`, I'm having trouble visualizing how that could be literally represented. Since the difference between one point and another is its coordinate, would we just see a point floating on the screen? Something like

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

On Sun, Jul 10, 2016 at 10:48 PM, Erica Sadun wrote: > > > On Jul 10, 2016, at 8:37 PM, Xiaodi Wu wrote: > > > > This is a neat idea, and I think a very sensible way to extend the > language. I worry only a little about the following: > > > >

[swift-evolution] [Pitch] Extending Swift Literals

This is purely additive and would not be eligible for Swift 3. gist: https://gist.github.com/erica/c92f6ab115af89d5c4b9161487df6a3c -- E Extending Swift Literals Proposal: TBD Author: Erica Sadun Status: TBD Review manager: TBD

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 8:37 PM, Xiaodi Wu wrote: > > This is a neat idea, and I think a very sensible way to extend the language. > I worry only a little about the following: > > Currently, unless preceded immediately by the keyword `fallthrough`, a > condition implicitly

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 10, 2016, at 8:36 PM, Taras Zakharko wrote: > > There is possible impact on existing code: a switch statement inside a loop, > that contains a continue. > > — Taras A switch statement within a loop may be broken by the introduction of `continue` semantics.

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ] (This is my second response to this proposal. The previous message shared a use case where public-but-non-subclassable made things work out much better with required

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

Well stated and has pushed me into favoring the closed be default case. I favor being explicit and the default being safe (you can always unseal in a future revision if a need arises). Also as you note it won't prevent bad implementations but it will help library developers better bound their

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

> On Jul 10, 2016, at 8:49 PM, let var go via swift-evolution > wrote: > > 2. The motivation seems to be that it will force better API design. No, that wasn’t my motivation in giving it a +1. This seems to be a common misunderstanding in the “no” camp, so I’ll

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

> On 11 Jul 2016, at 12:33 PM, Jonathan Hull wrote: > > It is pre-breaking in that it is the exact same code that doesn’t work in > both cases (only in the pre-breaking case, a bunch of other code also doesn’t > work). I know it feels different because it “was never possible”

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

This is a neat idea, and I think a very sensible way to extend the language. I worry only a little about the following: Currently, unless preceded immediately by the keyword `fallthrough`, a condition implicitly excludes all previous conditions. That is, if I write `switch .. { case a: ...; case

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

There is possible impact on existing code: a switch statement inside a loop, that contains a continue. — Taras > On 11 Jul 2016, at 04:27, Erica Sadun via swift-evolution > wrote: > > A quick pitch to introduce `continue` to switch statements. This would be >

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

> On Jul 10, 2016, at 6:45 PM, Rod Brown wrote: > > @Jonathan > > I don’t think that "pre-breaking code" is a good description. You are not > breaking anything - you’re just not allowing something that *could* become > unsafe. It’s safety first, at the cost of the

[swift-evolution] [Pitch] Introduce continue to switch statements

A quick pitch to introduce `continue` to switch statements. This would be additive and could not be considered for Swift 3. -- E Pitch: Introduce continue to Switch Statements Introduction This pitch completes the

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

Leonardo's example makes the case for why Swift should adopt a 'sealed' keyword that can be used to make public classes non-subclassable outside the module where they are defined, but not for why this should be the default. Others have made these points before, but these are the two biggest

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

@Jonathan I don’t think that "pre-breaking code" is a good description. You are not breaking anything - you’re just not allowing something that *could* become unsafe. It’s safety first, at the cost of the library user’s flexibility. That said, I actually think you have a good point however

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

>> >>> 2016/07/09 23:30、Matthew Johnson >> > のメール： >>> >>> This leaves the scenario of a case where you depend on a 3rd party, >>> closed-source library written in Swift and where you cannot get (or use) a >>> fix from the vendor for

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

This is the case with a library. It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. UIKit internally would therefore call directly to the

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

To highlight your comment below - I would favor “sealed” being available, I’m not sure I would favor it being the default. Would it help to perhaps split this into two proposals. First, decide on the issue of sealable being available first and syntax for it. If this passes then a second

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

> On Jul 9, 2016, at 16:37, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: > >> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He >> was working on a closed class

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

@Rod: Thank you for actually replying to the content of my post. Much appreciated. It is a trolly problem. You are arguing that pre-breaking everyone's code is better (even if causes way more trouble overall) than taking an action that breaks a few people’s code later (and thus feeling

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

> On Jul 9, 2016, at 01:44, Goffredo Marocchi wrote: > > > 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

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

> On Jul 8, 2016, at 23:47, L. Mihalkovic wrote: > > > > Regards > (From mobile) > > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > > wrote: > >> [Proposal: >>

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

I think folks are going in an unprofessional direction in this thread, let bring it back to a more positive direction please. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought. I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now

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

> You asked me to correct you and I shall: Well, in the first place, I asked how many subclasses you have to "seal" manually… may I assume that it is a low number? > You asked for an example where this feature would be needed and I've provided. No, actually you provided an example where you

Re: [swift-evolution] Change subscripts to use colons

Currently, the signature is: subscript(_ example: Int) -> Element { get { … } set { … } } The alternative, using a colon, would be: subscript(_ example: Int) : Element { get { … } set { … } } Sorry if that wasn't clear. This would be to better reflect the property-like nature of

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

> The problem with this is simple: you cannot retroactively "close up" an API. > I cannot add final to a class I have previously declared as non-final. I also > can seal a class which has previously been open to subclassing. Of course you can do both — it may make users angry, but so what? The

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

IMHO SE-0117 is one of the worst Swift 3 proposals that have ever been proposed. It has the potential to make the language much worse. I haven't seen any problems at all that are caused by people trying to subclass classes that they shouldn't, so I'm wondering where this fear of bad subclass

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] Change subscripts to use colons

> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution > wrote: > > Subscripts are a hybrid of properties and functions, since they have a > parameter list, as well as getters and setters, so use of either symbol will > be unusual in this case. > >

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

Yes, app. Apps can be extended through plugins and you cannot write a plugin to an app without a library that exposes what you can do. That alone can expand my simple sample into a variety of examples: plugins. For the many types of folders I cannot enter details of my app now but check macOS'

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

You asked me to correct you and I shall: you're wrong. Although it seems like a filesystem representation here, this is not it and the subclassability of Entry and File is intended but Folder is a special type and I cannot allow more than the base type and a few controlled subclasses due to the

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

I personally agree with most of your assessments. It's why I pushed so hard for "allow subclassing my default" in the first discussion of this point. The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as

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

I only had a passing glance but I'm a fan. > On 11 Jul. 2016, at 6:33 am, Jasdev Singh via swift-evolution > wrote: > > Hey Swift Evolution! > > Drafted up a small proposal that harmonizes the use of static functions and > static function properties in appropriate

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

> Should I assume then you want so much this proposal to be dropped you didn't > even mind to look for the example so you wouldn't have to admit this proposal > is needed? Fine, here is the whole of that example. This list has thousands of messages, this topic alone is split into at least six

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

> Tino Heth wrote: ...I challenged [supporters] to show a singe persuasive > example to illustrate that this proposal could actually improve > something...even if there are cases which cannot be repelled with the simple > advice "just don't subclass", this would only be a basis to start talking

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy. I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many

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

Hey Swift Evolution! Drafted up a small proposal that harmonizes the use of static functions and static function properties in appropriate protocol conformance scenarios:

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

Should I assume then you want so much this proposal to be dropped you didn't even mind to look for the example so you wouldn't have to admit this proposal is needed? Fine, here is the whole of that example. I'm currently working on an app which will have object representations of Files and

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] Addition of a standardError OutputStream

What is the process for smaller issues like these? I’m guessing that this doesn’t need a proposal; where should it go? On bugs.swift.org ? > On Jul 8, 2016, at 16:33, Erica Sadun wrote: > > Right now it's more like "foo".write(to: ) but I agree

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I appreciate the desire for consistency but I really don't like this proposal. I agree with others who've said that it makes the code look heavy and that the extra parens only obscure the actual code, at least when the code is short. I don't think there is any way in which the parens make the code

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

> Am 10.07.2016 um 19:34 schrieb Matthew Johnson : > > > > 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] [Review] SE-0117: Default classes to be non-subclassable publicly

> Am 08.07.2016 um 17:24 schrieb Matthew Johnson : > > > > Sent from my iPad > > On Jul 8, 2016, at 10:05 AM, Thorsten Seitz > wrote: > >> >> >> Am 08.07.2016 um 15:59 schrieb Matthew Johnson

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

> > Using the same language/syntax would eliminate the taxing mental > > context-switch. > I don't understand. That's the point of C++ interop... You call the C++ APIs > from your Swift code. The topic of this discussion is not calling *existing* C++ APIs. It’s about the possibility of writing

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

Two days ago, I challenged the supporters of this proposal to show a singe persuasive example to illustrate that this proposal could actually improve something. I got a single reply — which did not contain an example, but just the claim that there is one… Imho that alone should be enough to

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

Just to be crystal clear, here is my vision. Currently Swift is heading in this direction: SomeType.staticMember == metatypeInstance.staticMember == SomeType.self.staticMember SomeType.init == metatypeInstance.init == SomeType.self.init SomeType.self -> SomeType.Type (metatype) SomeType ->

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

On Jul 10, 2016, at 01:17, Georgios Moschovitis wrote: >> I *think* it'd be better to add C++ interoperability to Swift. > > Wouldn’t it be better to have unified syntax across the board? e.g., > > int x; -vs- x: Int, etc? > > Using the same language/syntax

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] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

> On Jul 4, 2016, at 5:32 PM, Andrew Trick via swift-evolution > wrote: > > >> On Jun 28, 2016, at 11:05 PM, Chris Lattner > > wrote: >> >> Hello Swift community, >> >> The review of “SE-0107: UnsafeRawPointer API”

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

Hi Chris, Yes, I did read it again, subscribe to that strategy. I’ve perhaps over-emphasized the importance of the impact back-breaking changes .. Still.. The subject title was a bit overloaded too. I guess it’s between two extremes: that is, between (1) really freezing it and (2) using

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

Hello Chris, my main concern for this change is the lack of extensibility of metatypes. We can access the metatype through the .self postfix, which potentially will be removed in the future (only the postfix). Through an instance of such a metatype we can then access the static members and all

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

This has been a very interesting and educational thread. Thanks to everyone who kindly replied to me and explained things. Here is my 2¢… > * What is your evaluation of the proposal? +0 as it stands… +1 if there could be a reliable way for us to explicitly un-seal a sealed class for those

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] Swift-based Metal Shading Language

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 that that will happen. The other discussion, which I think was the intended topic of this thread, is whether the benefits of

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

> Am 06.07.2016 um 13:39 schrieb Matthew Johnson via swift-evolution > : > > > > Sent from my iPad > >> On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution >> wrote: >> >> Huge +1. >> >> Question about inheritance though:

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] Swift-based Metal Shading Language

> I disagree. IMO, the ‘babel’ of programming languages is one of the most > annoying problems in our industry. Besides, I don’t see how C++ is any more > suitable than Swift for GPU/heterogenous stuff (without peculiar extensions > like CUDA). Swift is starting from a clean-slate, and could

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

> 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++ interoperability is orthogonal to my original request. Would love to have both! > Also, I think that the right language for the

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-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 10, 2016, at 1:37 AM, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: > >> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He >> was working on a closed class

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

> Perhaps not Metal per se, but the ability to compile code to a heterogenous > architecture. +1 > It seems like Swift has been laying a lot of the ground work to move in that > direction. I have the same *feeling* but I am wondering if there is any substance in this or it’s just wishful

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

> I *think* it'd be better to add C++ interoperability to Swift. Wouldn’t it be better to have unified syntax across the board? e.g., int x; -vs- x: Int, etc? Using the same language/syntax would eliminate the taxing mental context-switch. ___