Re: [swift-evolution] [Pitch] Adding safety to arrays

Dynamic programming comes to mind. Saagar Jha > On Apr 16, 2017, at 19:33, Riley Testut wrote: > > My bad, should have phrased my response better :^) > > Under what circumstances would you need to be able to assign elements in an > array out of order, while also requiring Array size/performan

Re: [swift-evolution] [Pitch] Adding safety to arrays

My bad, should have phrased my response better :^) Under what circumstances would you need to be able to assign elements in an array out of order, while also requiring Array size/performance? (Genuinely curious, not trying to attack). IMO, if the differences between Array and Dictionary would c

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> Using extensions for "code organization" is another word for writing > spaghetti code. Using extensions for code organization is a practice established and recommended by the Core Team from the very beginning (such as this blog post from August 2014: https://developer.apple.com/swift/blog/?id

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On 17 Apr 2017, at 00:46, David Hart wrote: Reply below. > And it's a style that is so widely used by the Swift community that even if > you think it's a bad practice does not change the fact that many people use > that style and that the current access level rules don't play well with them.

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

This continues to forbid use cases that are critical. For instance, I am writing a library that vends additional conformances for Float and Double. Any numerics library would need to do the same. Your design would eliminate all such libraries, which is a non-starter. I am not sure what defects yo

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

@Brent, I have updated the proposal to address your concerns, in particular I don't see that retrospectively adding methods and protocols has been removed it has just had its ugly corners rounded. See revised proposal below particularly the end of section "Retrospectively adding protocols and m

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

-1 from me. Using extensions for "code organization" is another word for writing spaghetti code. It results in types with many responsibilities. In such cases, it's time to extract collaborator types. But it sure looks prettier. R+ Sent from my iPhone > On 7 Apr 2017, at 10:56, Jonathan Hul

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 2:45 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 11:52 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull wrote: > >> >> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote: >> >> On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution <

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 11:52 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull > wrote: > >> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu > > wrote: >> >> On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution >

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:58 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> One benefit of the idea of using comparison metrics instead of changing >>

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull wrote: > > On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > The point is that, when you manipulate two real numbers, sometimes there > is no numeric result. You cannot simply wish this away with a

Re: [swift-evolution] [Pitch] Adding safety to arrays

A Dictionary uses a lot more space than an Array, though, and allow for bogus keys like “-1”, etc. Saagar Jha > On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution > wrote: > >> Personally, the only valid use-case I can think of is when you want to >> initialise an Array’s elements o

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution > wrote: > > The point is that, when you manipulate two real numbers, sometimes there is > no numeric result. You cannot simply wish this away with a new numeric type > because it is not an artifact of _modeling_ real numbers but r

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 10:45 AM, Xiaodi Wu wrote: > > On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > One benefit of the idea of using comparison metrics instead of changing > comparable, is that you could just have two metrics o

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:35 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > One benefit of the idea of using comparison metrics instead of changing > comparable, is that you could just have two metrics on double. The default > one which is closer to what we have now

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 12:30 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 16, 2017, at 09:56, Nevin Brackett-Rozinsky via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Another option is to make a new type, not sure what to call it but I’ll

Re: [swift-evolution] [pitch] Comparison Reform

One benefit of the idea of using comparison metrics instead of changing comparable, is that you could just have two metrics on double. The default one which is closer to what we have now (or the new thing Xiaodi suggested with trapping NaN), and one which matches IEEE. You could in fact make a

Re: [swift-evolution] [Pitch] Adding safety to arrays

> Personally, the only valid use-case I can think of is when you want to > initialise an Array’s elements out-of-order - i.e., you want to set a value > for myArray[2] despite myArray[0] and [1] not being populated. In that case, > it would be better to have some kind of SparseArray type, and fo

Re: [swift-evolution] [pitch] Comparison Reform

Interesting… I think this is my favorite option so far. I think we had an argument about this before, but if we could just make ‘<‘ throwing by marking it ‘throws!’ (that defaults to a trap unless ‘try’ or ’try?' is used), it would simplify the whole scheme to not require extra operators (thoug

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 16, 2017, at 09:56, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Another option is to make a new type, not sure what to call it but I’ll use > “Num” for now, that is essentially the same as Double except it does not > represent NaN. After all, why should a numeric type ev

Re: [swift-evolution] [pitch] Comparison Reform

See, your design still takes as given that floating point values require more than one type of comparison, however these are spelled. I continue to think that we do not need to go down this road, and that we can make things work with each type being comparable in exactly one way. The only wrinkle

Re: [swift-evolution] [pitch] Comparison Reform

Another option is to make a new type, not sure what to call it but I’ll use “Num” for now, that is essentially the same as Double except it does not represent NaN. After all, why should a numeric type ever be “not a number”, and what sort of name is “Double” anyway except as a hold-over from legacy

Re: [swift-evolution] [pitch] Comparison Reform

> On 16 Apr 2017, at 18:35, Karl Wagner wrote: > >> >> On 16 Apr 2017, at 05:32, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Sat Apr 15 2017, Xiaodi Wu > > wrote: >> >>> On Sat, Apr 15, 2017 at 3:12 PM, Dave Ab

Re: [swift-evolution] [pitch] Comparison Reform

> On 16 Apr 2017, at 05:32, Dave Abrahams via swift-evolution > wrote: > > > on Sat Apr 15 2017, Xiaodi Wu > wrote: > >> On Sat, Apr 15, 2017 at 3:12 PM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> on Thu Apr 13 2017

Re: [swift-evolution] [pitch] Comparison Reform

On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > >> > I have an incipient idea. It begins with: > >> > > >> > enum ComparisonResult { > >> > case orderedAscending, orderedSame, orderedDescending, unordered > >> > } > >> > > >> > I am sur

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

I have to say that — while the concerns of the others are certainly valid, especially with regards to namespacing — I do like this idea, especially how it unifies access control of lexical scopes with that of types and friends. -Thorsten > Am 14.04.2017 um 22:58 schrieb Erica Sadun via swift-e

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On 15. Apr 2017, at 22:12, Philippe Hausler wrote: > > > >> On Apr 14, 2017, at 22:51, Martin R > > wrote: >> >> Thank you for the response, but I have more questions. Will >> >> Float(exactly: NSNumber(value: Double.pi)) > > This will succeed in that the