Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

on Wed Jun 14 2017, Chris Lattner wrote: >> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >> wrote: >> >> Some pals and I have been kicking an idea around about introducing >> better ways to support the compiler in protocol extensions. We want > >> to eliminate some hard-to-det

Re: [swift-evolution] Revisiting SE-0110

It declares variables Int and Float, but I know that only because CodaFi asked us the same question on twitter a while back! I'd be very happy if that was deprecated. > On 15 Jun 2017, at 06:01, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wr

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sent from my iPhone > On 15 Jun 2017, at 05:41, Paul Cantrell via swift-evolution > wrote: > > >>> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution >>> wrote: >>> >>> >>> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution >>> wrote: >>> >>> On 14.06.2017 21:23, Haravi

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 6:01 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: >> >> What’s the status of this Chris’s double parens idea below? It garnered some >> positive responses, but the discussion seems to have fizzled out. Is ther

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution > wrote: > > >> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swif

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution > wrote: > > Some pals and I have been kicking an idea around about introducing better > ways to support the compiler in protocol extensions. We want to eliminate > some hard-to-detect bugs. We've been brainstorming on how to do

Re: [swift-evolution] Revisiting SE-0110

> On Jun 12, 2017, at 10:07 PM, Paul Cantrell wrote: > > What’s the status of this Chris’s double parens idea below? It garnered some > positive responses, but the discussion seems to have fizzled out. Is there > something needed to help nudge this along? > > What’s the likelihood of getting

[swift-evolution] The state and the future of function types in Swift 4

I do understand that core team is very busy, but I hope they'll find a minute to reply in couple of words to this message. Even "we are still thinking about this" would be great. Of course any other's opinion is also very welcome. I think we all need some clarification about function types in S

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On 15.06.2017 0:51, David Hart wrote: On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution > wrote: On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution mailto:swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution > wrote: > > On 14.06.2017 21:23, Haravikk via swift-evolution wrote: >>> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via sw

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On 14 Jun 2017, at 23:22, Goffredo Marocchi via swift-evolution wrote: >> Yes, I think we are all in vigorous agreement about this. The question is >> whether, at this point in Swift's evolution, a wide-ranging migration due to >> a new required keyword will be well tolerated. If not, then the

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On 14 Jun 2017, at 20:19, Matthew Johnson wrote: > > >> On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu > > wrote: >> On Wed, Jun 14, 2017 at 1:01 PM, David H

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sure, it’s not out of the question, technically. The question is whether a migration of such scale is desirable, which is a difficult judgment call. On Wed, Jun 14, 2017 at 16:43 David Hart wrote: > On 14 Jun 2017, at 20:19, Matthew Johnson wrote: > > > On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sent from my iPhone > On 14 Jun 2017, at 21:41, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Jun 14, 2017 at 3:37 PM, Vladimir.S via swift-evolution >> wrote: >>> On 14.06.2017 21:23, Haravikk via swift-evolution wrote: >>> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

> On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 14 2017, Philippe Hausler > wrote: > >> After implementing the proposal >> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md >>

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

is and as are implemented in the compiler to call the same method Sent from my iPhone > On Jun 14, 2017, at 1:38 PM, Xiaodi Wu wrote: > > In SE-0170, it states: "It is worth noting that `is` should follow the same > logic as `as?`." For clarity, does rolling back to the initial Swift 3 > beha

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

on Wed Jun 14 2017, Philippe Hausler wrote: > After implementing the proposal > https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md > > we have gotten some initial feedback

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On Wed, Jun 14, 2017 at 3:37 PM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > On 14.06.2017 21:23, Haravikk via swift-evolution wrote: > >> >> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org > wrote:

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

In SE-0170, it states: "It is worth noting that `is` should follow the same logic as `as?`." For clarity, does rolling back to the initial Swift 3 behavior mean that `NSNumber(value: 0.1) is Float == true`? On Wed, Jun 14, 2017 at 3:13 PM, Philippe Hausler via swift-evolution < swift-evolution@swi

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On 14.06.2017 21:23, Haravikk via swift-evolution wrote: On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution > wrote: On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution mailto:swift-evolution@swift.org>> wrote: Sorry, initially sent off

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I like the idea of fixing this area of the language and I’m happy to see others already pointed out that extend could be implicit and does not need to be introduced at all, where default would become necessary for protocol default implementations. If I’m not mistaken this _can_ be an improvemen

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I agree with omitting the extend keyword, as it does not really add anything useful to the language. The default keyword, on the other hand, seems as if it will be really useful for extending protocols. It would be useful for a handful of cases, and it further introduces safety to Swift as a who

[swift-evolution] Followup after in-the-field feedback for SE-0170

After implementing the proposal https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md we have gotten some initial feedback. It seems that there is definitely a fair amount

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> El 14 jun 2017, a las 20:01, David Hart via swift-evolution > escribió: > > I think this proposal is a great idea. But I would vote for the alternative > of only having default and implicitly deducing extend when default is not > specified: it would mimic how override works with only one key

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 1:23 PM, Haravikk via swift-evolution > wrote: > > >> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 12:01 PM, Dave Abrahams wrote: > >> >> on Wed Jun 14 2017, Xiaodi Wu wrote: >> >> > On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: >> > >> >> If we leave aside for a moment the nomenclature issue where everything >> in >> >> Found

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution > wrote: > > On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Sorry, initially sent off-list: > > I think this proposal is a great idea. But I would vote for the alternative

Re: [swift-evolution] Swift phases and mis-timed proposals

> Not even just for development… a standard repository for “substandard” > library(s) would be a great for commonly used types that aren’t quite > commonly used enough to include in stdlib, and IMHO, could really help > Swift’s ecosystem (I’m not claiming that it’s poor now or anything, but >

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution > wrote: > > On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu > wrote: > On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Sorry, initially sent off-l

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > >> Sorry, initially sent off-list: >> >> I think this proposal is a great idea. But I would vote for the >> alternative of only having defaul

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Sorry, initially sent off-list: > > I think this proposal is a great idea. But I would vote for the > alternative of only having default and implicitly deducing extend when > default is not specif

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

On Wed, Jun 14, 2017 at 12:01 PM, Dave Abrahams wrote: > > on Wed Jun 14 2017, Xiaodi Wu wrote: > > > On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: > > > >> If we leave aside for a moment the nomenclature issue where everything > in > >> Foundation referring to a character is really referring

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Sorry, initially sent off-list: I think this proposal is a great idea. But I would vote for the alternative of only having default and implicitly deducing extend when default is not specified: it would mimic how override works with only one keyword, it would not introduce a completely new keywo

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I like this proposal a lot and also like Xiaodi’s suggestion that these be made into @ attributes. > On Jun 14, 2017, at 1:48 PM, Xiaodi Wu via swift-evolution > wrote: > > I like that this is minimal impact because it is optional. Since it is > optional, I wonder if making it visually distin

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I like that this is minimal impact because it is optional. Since it is optional, I wonder if making it visually distinct from the mandatory keywords such as "override" for classes would be optimal, perhaps by making these @annotations. Otherwise the naming is near perfect, IMO. It follows by analo

Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

> On Jun 14, 2017, at 2:24 AM, David Hart wrote: > Very good description. It's always worth re-explaining terms like bridged > conversion to make sure every body is on the same page. But concerning the > rules at the end, I’m not quite sure I understood them all. Please let me > know if I’m cor

[swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Some pals and I have been kicking an idea around about introducing better ways to support the compiler in protocol extensions. We want to eliminate some hard-to-detect bugs. We've been brainstorming on how to do this without affecting backward compatibility and introducing a minimal impact on ke

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: > >> If we leave aside for a moment the nomenclature issue where everything in >> Foundation referring to a character is really referring to a Unicode >> scalar, Kevin’s example illustrates the whole problem i

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams wrote: > >> >> on Wed Jun 14 2017, Xiaodi Wu wrote: >> >> > However, if this desire to remove failable APIs remains strong then I >> > wonder if the undiscussed second option above is worth at least some >>

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 13, 2017, at 3:21 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Jun 12 2017, David Waite > wrote: > >> So is the idea of the Index struct is that the encodedOffset is an >> offset in the native representation of the string (byte offse

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams wrote: > > on Wed Jun 14 2017, Xiaodi Wu wrote: > > > If we leave aside for a moment the nomenclature issue where everything in > > Foundation referring to a character is really referring to a Unicode > > scalar, Kevin’s example illustrates the who

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > If we leave aside for a moment the nomenclature issue where everything in > Foundation referring to a character is really referring to a Unicode > scalar, Kevin’s example illustrates the whole problem in a nutshell, > doesn’t it? In that example, we have a

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: > If we leave aside for a moment the nomenclature issue where everything in > Foundation referring to a character is really referring to a Unicode > scalar, Kevin’s example illustrates the whole problem in a nutshell, > doesn’t it? In that example, w

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

If we leave aside for a moment the nomenclature issue where everything in Foundation referring to a character is really referring to a Unicode scalar, Kevin’s example illustrates the whole problem in a nutshell, doesn’t it? In that example, we have a straightforward attempt to slice with a misalign

Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

+Int.max Charles > On Jun 14, 2017, at 1:24 AM, David Hart via swift-evolution > wrote: > > Very good description. It's always worth re-explaining terms like bridged > conversion to make sure every body is on the same page. But concerning the > rules at the end, I’m not quite sure I understo

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 13, 2017, at 6:16 PM, Xiaodi Wu wrote: > > I’m coming to this conversation rather late, so forgive the naive question: > > Your proposal claims that current code with failable APIs is needlessly > awkward and that most code only interchanges indices that are known to > succeed. So, w

Re: [swift-evolution] [Proposal] Change Void meaning

@john, the proposal is the fruit of my imagination and the goal was to discuss about it. I’m vastly open to change it with the help of anyone if it can be implemented in a simple way and leads to better compatibility or syntactical improvements. xiaodi told me that he wouldn’t be available to help