Re: [swift-evolution] Stdlib closure argument labels and parameter names

On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams wrote: > > on Sun Jun 26 2016, Xiaodi Wu wrote: > > > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> See below. But in a nutshell, `do` gets the idea across. It's short. > >> I

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

On Mon, Jun 27, 2016 at 6:47 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jun 23 2016, Xiaodi Wu wrote: > > > On Thu, Jun 23, 2016 at 1:26 AM, David Sweeris via swift-evolution < > > swift-evolution@swift.org> wrote: > > > >> > >> > On Jun 22, 2016, at 19:3

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

On Tue, Jun 28, 2016 at 1:25 PM, David Hart wrote: > > > > On 28 Jun 2016, at 13:46, Brent Royal-Gordon > wrote: > > > > Unlike the other methods, adding additional elements changed the length > of `suffix(from:)`'s return value. That indicates to me that it is *not* a > suffix operation at all.

Re: [swift-evolution] Add an implicit return nil if function reaches end before return explicitly called

On Tue, Jun 28, 2016 at 12:10 PM, Logan Sease via swift-evolution < swift-evolution@swift.org> wrote: > So this particular construct is one that comes from the ruby language. > In Ruby, you don’t explicitly have to return at all, but rather your last > statement will always return by default. > I

Re: [swift-evolution] Prohibit invisible characters in identifier names

Yes. See earlier in the discussion about the Unicode confusables list. The security issues that arise from confusable URLs aren't the same as those for identifiers in Swift, and I think the short version of the previous discussion is that prohibiting the use of Greek nu and mathematical bold italic

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

I understand that that's your thinking. I just don't understand how you arrived at your rule (2). It's not in the dictionary definition of the words prefix and suffix. Nor do I find any documentation of such a rule in Swift. Nor do I think you've shown that such a rule is necessary for clearing up

Re: [swift-evolution] Setter methods for vars

As an additive feature it's unlikely to be considered in the Swift 3 timeline anyway. You can search the list archive for previous discussion on lenses. I think David is saying that this proposal looks like it's asking for a special case where a more general solution might be appropriate. On Tue, J

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

On Tue, Jun 28, 2016 at 9:06 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 28, 2016, at 19:03, Matthew Judge wrote: > > Comments inline. > > On Jun 28, 2016, at 04:14, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello everybody, >

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 29, 2016, at 10:46 AM, Sean Heber wrote: > > > On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jun 29, 2016, at 10:

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

On Wed, Jun 29, 2016 at 10:37 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > >> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution < > swift

Re: [swift-evolution] modifying Array to return Element! when subscripted

On Wed, Jun 29, 2016 at 10:06 AM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote: > What about an additional method? No subscripting, just a method that > throws instead of trapping? > What about it? You can add it yourself via extension. What's your case that it should be in

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

On Wed, Jun 29, 2016 at 11:03 AM, Matthew Johnson wrote: > > On Jun 29, 2016, at 10:55 AM, Xiaodi Wu wrote: > > On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org>wrote: > >> >> On Jun 29, 2016, at 10:46 AM, Sean Heber wrote: >> >> >> On Jun 29,

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

On Wed, Jun 29, 2016 at 11:14 AM, Austin Zheng wrote: > I just want a name that is: > > - a single English language word > - whose common meaning has something to do with privacy, access, > permissions, or a similar grouping concept that the other three keywords > fits into > - and intuitively de

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

On Wed, Jun 29, 2016 at 11:19 AM, Sean Heber wrote: > > Agreed. I'd have to be convinced that having aliases provide > overwhelming wins at the call site that could not be achieved through > renaming. Although aliasing could be very neat in certain circumstances, I > fear that admitting such a fa

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

On Wed, Jun 29, 2016 at 11:31 AM, Jordan Rose wrote: > > On Jun 29, 2016, at 08:49, Xiaodi Wu wrote: > > On Tue, Jun 28, 2016 at 9:06 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jun 28, 2016, at 19:03, Matthew Judge wrote: >> >> Comments inline. >> >> On

Re: [swift-evolution] Feature proposal: Range operator with step

I'm confused. There is an instance owning the start and end. It's called StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that it should conform to Collection) and is distinct from Range and from the Strideable bounds themselves. Is that different from what you're describing?

Re: [swift-evolution] Feature proposal: Range operator with step

Conceptually, maybe? But of course the sequence is lazily evaluated, so the only state stored in an instance of StrideTo is one value for the current iteration; all the other properties in a StrideTo are just the inputs to the stride function, and no length is computed let alone stored. I get that

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

If we're going to bikeshed again: how about "assign"? On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote: > replaceWith* is also my favourite here (same for *InPlace). Sure, it might > be verbose, but the semantics is very clear and seems apply to

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 1:00 AM, Brent Royal-Gordon wrote: >> We propose to introduce a striding(by:) method on the revised 3.0 Range type. > > I take it that we're taking an incremental approach here, Yes, other proposals are on their way to complement this one. > and further steps like: > > * A

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 2:49 AM, Michel Fortin wrote: > Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution > a écrit : >> >> (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1] > > The above reads wrong to me. The expression has to be read differently > depending on the tinny detail that is the s

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sat, Apr 9, 2016 at 5:44 AM, Wallacy via swift-evolution wrote: > Just as note, i think the sintax should be: > > 0...9 > 0..<9 > 0>..9 > 0>.<9 > > Because the intention is produce a number bigger than 0 (start). So greater > than zero less than nine. That's not typically how it's written in m

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I agree with 90% of your comment. But, ranges are useful for more than just stride, and so I would say it doesn't make sense to have an intrinsic direction for Range, which pointedly has lowerBound and upperBound but not start and end. For sample, there shouldn't be (0...9).contains(1) and (9...0)

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Indeed. It's noted under "design concerns" and, IMO, raises the bar for their addition. On Sat, Apr 9, 2016 at 12:05 PM Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > Re: "Completing the Swift 3 range operator suite" >

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

The sign of the stride size is already (in the current version of Swift) evaluated in the stride generator/iterator; as written, it is evaluated every time next() is called, but of course that is optimized away when possible. What we are proposing adds no additional logic to the loop. I can't see a

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

IMO, 9...0 is a non-starter. Especially with Range taking on the role of Interval, it's critical that they have no direction. Suppose you have two ranges, 0...9 and 9...0. Is 0...9 == 9...0? IMO, two countable ranges r0 and r1 are equal if, for value in r0, r1.contains(value) == true, and vice vers

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Yikes. Not too concerned about the infinite loop issue, as floating point strides when fixed to avoid error accumulation will necessarily enforce a finite number of steps. However, you're talking a regular, not-at-all-lazy Array being returned? That would be not good at all... On Sun, Apr 10, 2016

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

We will be proposing exactly that which you've put in parentheses, i.e. floating point types will get their own strides, and it will be a precondition failure to try to stride from or to infinity or nan :) On Sun, Apr 10, 2016 at 4:47 AM wrote: > It’s not a matter of floating point error accumul

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

The iteration counter will be floating point and the iterator will break down after incrementing by one is no longer exactly representable. It has been made clear on this list that there is a strong preference that no floating point stride should degenerate into an infinite loop due to this issue.

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

What types do you have in mind that would only support positive distances? All numeric types (yes, even UInt, etc.) have signed distances, which reflects the basic mathematical abstraction of a number line. A consistent behavior with signed distances is so important that we are currently strugglin

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Sun, Apr 10, 2016 at 3:58 PM, Haravikk wrote: > > On 10 Apr 2016, at 14:25, Xiaodi Wu wrote: > > What types do you have in mind that would only support positive distances? > All numeric types (yes, even UInt, etc.) have signed distances, which > reflects the basic mathematical abstraction of a

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I realize what follows is actually an argument for restricting stride to collections with randomly accessible elements, and maybe we should: We've touched a little bit on performance, and I think my feeling with stride is that just the name itself suggests a certain logic--namely, that we actually

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Fair enough. If we go this direction, there's little sense in conforming StrideTo and friends to Collection at the moment, I suppose? On Mon, Apr 11, 2016 at 9:56 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Xiaodi Wu wrote: > > > I realize what

Re: [swift-evolution] [Accepted] SE-0057: Make unsafe pointer nullability explicit using Optional

Has there been a mix-up with the title of the proposal in the subject line? On Thu, Apr 14, 2016 at 5:59 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md > > Th

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

* What is your evaluation of the proposal? +1 in intent. Specifics require further refinement. For example: Internal inconsistencies in capitalization: * `signalingNaN` but `isSignalingNan` and `isNan` Parameter labels, or whatever they're called now, do not reflect newly adopted Swift syntax i

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

On Wed, Apr 20, 2016 at 5:38 AM, Stephen Canon wrote: > Hi Xiaodi — > > Thanks for the detailed comments. Some thoughts inline. > >> On Apr 19, 2016, at 6:34 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? &

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

Some thoughts inline. >>> >>>> On Apr 19, 2016, at 6:34 PM, Xiaodi Wu via swift-evolution >>>> wrote: >>>> >>>> * What is your evaluation of the proposal? >>>> >>>> +1 in intent. Specifics require further

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

I'm saying something else. The preposition that goes with "less" is "than," while "to" goes only with "equal." By making "to" a parameter label you've got {less than or equal} to, which is inelegant because the label cannot be distributed to both parts--i.e. one cannot say "less than to or equal to

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

issue it differently: > > - isLessThanOrEqual(to:) => isNotGreaterThan(_:), isAtOrBelow(_:), etc. > > …neither of which I can claim to really like, but such possibilities exist. > > Offering in case there's a better phrasing along similar lines. > > On Apr 20, 2016,

Re: [swift-evolution] [Review] SE-0067: Enhanced Floating Point Protocols

), isAtOrBelow(_:), etc. >> >> …neither of which I can claim to really like, but such possibilities >> exist. >> >> Offering in case there's a better phrasing along similar lines. >> >> On Apr 20, 2016, at 3:08 PM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:13 AM, Stephen Canon via swift-evolution wrote: > > On Apr 21, 2016, at 9:13 PM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md] > > This is super impressive. I do have several bits I’m

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Two stray thoughts: I agree with previous comments that `ulpOfOne` may not really be necessary. Of the following-- ``` init(signBit: Bool, exponent: Int, significand: Self) init(magnitudeOf other: Self, signOf: Self) ``` --would it be more elegant to have the latter be `init(signOf: Self, mag

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: > > On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

One more stray thought: Is there a reason RawSignificand is declared in FloatingPoint but used only in BinaryFloatingPoint? On Fri, Apr 22, 2016 at 10:02 AM, Xiaodi Wu wrote: > Two stray thoughts: > > I agree with previous comments that `ulpOfOne` may not really be necessary. > > Of the followin

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: > > On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: > > Naive question: is it necessary to make a trade-off here? Why not an > associated type Exponent that's Int for Float, Double, and Float80, > allowing for something else for bignums? > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: > >> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: >> >> On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: >>> >>> On Apr 22, 2016, at 10:54 AM, Xiaodi Wu wrote: >>> >>> Naive question: is it necessary to make a trade-off here? Why not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon wrote: > >> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: >> >> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: >>> On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: On Fri, Apr 22, 2016 at 9:56 AM, Stephen Canon wrote: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Fri, Apr 22, 2016 at 11:09 AM, Xiaodi Wu wrote: > On Fri, Apr 22, 2016 at 11:04 AM, Stephen Canon wrote: >> >>> On Apr 22, 2016, at 11:58 AM, Xiaodi Wu wrote: >>> >>> On Fri, Apr 22, 2016 at 10:31 AM, Stephen Canon wrote: > On Apr 22, 2016, at 11:26 AM, Xiaodi Wu wrote: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Neither, actually. NaN is a valid value and even its use does not always lead to exceptions. For example, it's possible (and a deliberate use case) to assign NaN (even signaling NaN), and the IEEE 754 function maxNum(x, y) (here proposed as `maximum`) will return x if x is not NaN and y is NaN. On

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

Not an expert on Obj-C compatibility in Swift by any means, but this reads like it's largely a change of nomenclature. To me, though, `objcoptional` reads exceedingly poorly. Why not emphasize the Obj-C compatibility angle by requiring the `@objc` attribute to precede each use of `optional`? (In ot

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

...assuming, of course, that you're putting forward a draft proposal about Swift that happens to be modest in scope, and not a Swiftian modest proposal . On Fri, Apr 22, 2016 at 7:56 PM, Xiaodi Wu wrote: > Not an expert on Obj-C compatibility in S

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

ot;decaffeinated coffee, $2" because it's easier to read. > To me, it's like a restaurant owner who complains that some customers say > "please" while other customers don't. For better consistency, he now forces > each customer to say "please" as well

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

On Sun, Apr 24, 2016 at 11:01 AM, Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > > The idea of distinguishing all mutating/non-mutating functions with only > the assignment operator did occur to me as I wrote that. > > Using such a rule would allow automatic generation of

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 5:28 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > Is there a reason that NaN can’t just compare in a more useful way, e.g- > always return true for the less than operator unless the other value is > also NaN, thus ensuring it always comes first in

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

On Sun, Apr 24, 2016 at 4:51 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > However, I don’t understand how that would help for floating point NaN > behavior. Wouldn’t you have to add a fourth member to the enum > (“unordered’) that all clients would have to ha

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Sun, Apr 24, 2016 at 4:28 PM, Chris Lattner wrote: > > > On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > > > Sent from my iPhone > > > >> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: > >> > >> Not an expert on Obj-C compatibil

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

I think there are some good points here. As a riff, though, I'd argue that Obj-C optional should *not* be renamed to elective or something else. Renaming, so far, has been for the purpose of providing first-class Swifty idioms for existing things. It makes moving between Swift-native code and legac

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

Me: Unless the functions also return an error, mutating/non-mutating pairs of functions return Void/Self (or maybe Optional) respectively. Are there other possibilities? But Swift is pretty unique among C-family languages in allowing overloaded functions that differ only by return type. Besides th

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Mon, Apr 25, 2016 at 5:08 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Apr 24 2016, Chris Lattner wrote: > > >> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> > >> > >> Sent from my iPhone

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Quick thought: Why are you reaching for the "form..." rule for the mutating methods when there are clear verb counterparts? location: locate successor: succeed On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Apr 20 2016, Chris La

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Mon, Apr 25, 2016 at 1:32 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> func isEqual(to other: Self) -> Bool > >> func isLess(than other: Self) -> B

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> > * What is your evaluation of the proposal? > Improved. Suggestions re naming of `isLessThanOrEqualTo(_:)`: "Less-than" can be regarded as a unit. Thus, `isLessThan(_:)` is reasonable. However, `isEqualTo(_:)` is kind of a stretch, but it could just be `equals(_:)`. Thus, you could hav

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when there > > are clear verb counterparts? > > location: locate > > successor: succeed > > We're not

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Yup, we're going to try to touch base, the authors of the current draft that is, sometime this week. More to come, hopefully. On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Dave Abrahams wrote: > > > on Sun Apr 10 2

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > wrote: > > > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > > > Quick thought: > > > > > > Why are you reaching for the "form..."

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

+1 to Tony's write-up. On Tue, Apr 26, 2016 at 10:47 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > That seems like a purely syntactic concern that could potentially be > addressed in other ways, though. I'm not sure the choice of "duplicate all > operators using verbosel

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Tue, Apr 26, 2016 at 12:36 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Apr 26, 2016 at 4:28 PM, Tony Allevato > wrote: > >> On Sun, Apr 24, 2016 at 2:57 AM Nicola Salmoria via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> > > func isEqu

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

Again, +1 to Tony's analysis. In the context of numerics in particular, global functions and operators are very much "normal means," and if anything instance methods are rather "convenience." On Tue, Apr 26, 2016 at 13:36 Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > On T

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

If this design is a workaround for type checker limitations, then perhaps comparison method names are better prefixed with an underscore and/or using abbreviated terms-of-art (eq, lt, lte, etc.)? As Tony points out, it seems tragic to promote to an equal footing with `2.0 + 2.0 == 4.0` the alternat

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

On Tue, Apr 26, 2016 at 4:08 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 25 2016, Erica Sadun wrote: > > > On Apr 25, 2016, at 7:15 PM, Xiaodi Wu via swift-evolution > > wrote: > > > > Yup, we're go

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Unrelated to this discussion about comparison operators, please remember to put back .abs() or .absoluteValue() somewhere in FloatingPoint. Thanks! On Tue, Apr 26, 2016 at 12:07 PM, Nicola Salmoria via swift-evolution < swift-evolution@swift.org> wrote: > If performance is the only reasons to ha

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

I thought you'd mentioned that AbsoluteValuable conformance was removed for a reason and that the method would be added to FloatingPoint? Otherwise, it seems like conformance to AbsoluteValuable would be much the same... On Tue, Apr 26, 2016 at 6:54 PM, Stephen Canon wrote: > Do you actually wa

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

How is retroactive modeling accommodated in this scheme? Say I want to conform three types I don't own to a protocol of my design and supply a default implementation for a protocol requirement. How would I go about it? On Thu, Apr 28, 2016 at 11:53 Erica Sadun via swift-evolution < swift-evolution@

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

On Thu, Apr 28, 2016 at 12:25 PM, Erica Sadun wrote: > > > > On Apr 28, 2016, at 11:05 AM, Xiaodi Wu wrote: > > > > How is retroactive modeling accommodated in this scheme? Say I want to > conform three types I don't own to a protocol of my design and supply a > default implementation for a prot

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

Right, sorry, I should have clarified. The scenario to be supported here is that the code for structs A, B, and C cannot be modified. They could be part of the stdlib, for example, or a closed-source third-party library. On Thu, Apr 28, 2016 at 1:18 PM, Matthew Johnson wrote: > > > Sent from my

[swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

We all know and love sizeof(), but given that it's different from its C counterpart anyway, shouldn't these conform to Swift naming guidelines? In other words, after SE-0006, shouldn't these names be as follows? ``` size(of: T.Type) size(ofValue: T) stride(of: T.Type) stride(ofValue: T) align(of:

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

I'm not sure that I'm entirely happy with this distinction between already compiled types and ones that have not yet been compiled. It's a common Swift idiom to implement protocol requirements in extensions, which encourages a kind of modularity, if you will. Every so often (and maybe this isn't be

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

Why allow both `override` and `required`? I understand you mean it to indicate that you're overriding a requirement, but does that provide any additional safety? Both say "I intend to name something the same as something else." In addition, the juxtaposition of both keywords can be misunderstood.

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

ult implementations } extension PortedTransform : AcceleratedTransform { // use BLAS to implement scale(_:) and unscale(_:) } ``` On Apr 28, 2016, at 5:24 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm not sure that I'm entirely happy with

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

On Thu, Apr 28, 2016 at 8:32 PM, Erica Sadun wrote: > > On Apr 28, 2016, at 6:20 PM, Xiaodi Wu wrote: > > On Thu, Apr 28, 2016 at 6:44 PM, Erica Sadun wrote: > >> Can you give me a specific example of where this approach fails for you? >> >> -- E >> > > > Sure, I'll describe one (renaming some

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

My bad for such a convoluted example. All of this is trying to say something rather simple: I'm sure almost all of you who've worked with C++ have used Boost header-only libraries. Many of them are really nice. There are reasons why third-party Swift code might be distributed by one person and in

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

On Thu, Apr 28, 2016 at 9:25 PM, Erica Sadun wrote: > On Apr 28, 2016, at 8:11 PM, Xiaodi Wu wrote: > > > Sorry, stripped out a little too much, I guess. Let me expand a little: > > In this example, `PortedTransform` has, by virtue of how it works, an > upper bound and lower bound for valid inpu

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

On Thu, Apr 28, 2016 at 9:40 PM, Erica Sadun wrote: > > Without actually trying to understand the details of your math stuff: > > * If you add a required member in a declaration or extension that declares > conformance, it is 'required'. > * If it is already defaulted, it is `override required`. >

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

On Thu, Apr 28, 2016 at 9:53 PM, Erica Sadun wrote: > > On Apr 28, 2016, at 8:46 PM, Xiaodi Wu wrote: > Let's return to the toy example. Suppose I license the following code from > a third party. I am allowed to incorporate it unmodified into my project: > > ``` > // I cannot touch any of the fo

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

I'd be keenly interested in something that would improve the experience of conforming a type to a protocol. I think others would as well. A sufficiently sophisticated solution would: * catch unintentional typos that cause required functions to be incorrectly named * show, ideally prospectively, wh

Re: [swift-evolution] Protocol non-conformance clause

Yes, certainly this works today. The motivation for Erica's question is that this would not work without modifying the third-party code if keywords were required to indicate implementation of protocol requirements. One possible solution might emerge if it is possible to extend a protocol condition

Re: [swift-evolution] Eliminate inconsistencies among primary collection types

I'm not sure I understand the inconsistency you see. Set and Dictionary require hashable values and keys, respectively. That's just in the nature of what these types are. Do you want Set itself to conform to Hashable? On Fri, Apr 29, 2016 at 12:57 Wolfgang H. via swift-evolution < swift-evolution@

Re: [swift-evolution] Eliminate inconsistencies among primary collection types

On Fri, Apr 29, 2016 at 2:49 PM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 29, 2016, at 1:57 PM, Wolfgang H. via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Inconsistency A. is that “Set” currently is the only collection type > conforming to pro

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

ft-evolution@swift.org>> wrote: > > > On Apr 28, 2016, at 11:44 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote: > > We all know and love sizeof(), but given that it's different from its C > counterp

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

On Sun, May 1, 2016 at 4:54 AM, Brent Royal-Gordon wrote: > > With the renaming proposed above, stride(of:) will appear to be related > to stride(from:to:by:). This conflict arises from a pre-existing issue; > namely, the term "stride" is used to mean two different things. Although > moving the p

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I think I agree with you that stride(from:to:by:) is the better candidate for renaming. But, ranges and strides are distinct in Swift, and I don't think we want to confuse the two, especially since ranges and intervals are already being merged. A few of us have some ideas about striding over things

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

A clash of names is inelegant, but in practice, I'm not actually sure that there's really a lack of clarity. IMO, `stride(of: Int)` is not really misinterpretable as anything else. On Sun, May 1, 2016 at 12:08 PM, Shawn Erickson wrote: > I personally kinda want to see these namespaced instead o

Re: [swift-evolution] Protocol non-conformance clause

The point is pretty much moot. In Erica's draft proposal, keywords are required in any Swift code that hasn't been compiled in order to indicate conformance. Under that scheme, it might be useful to be able to express something like what Erica asked about in this email thread. I understood it to be

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

On Sun, May 1, 2016 at 7:00 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Apr 28 2016, Xiaodi Wu wrote: > > > We all know and love sizeof(), but given that it's different from its C > > counterpart anyway, shouldn't these conform to Swift naming guidelines?

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

On Sun, May 1, 2016 at 7:01 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun May 01 2016, Xiaodi Wu wrote: > > > A clash of names is inelegant, but in practice, I'm not actually sure > that > > there's really a lack of clarity. IMO, `stride(of: Int)` is not rea

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

See: // FIXME(ABI)(compiler limitation): We'd like to name this type "Distance" // but for On Sun, May 1, 2016 at 20:51 Dave Abrahams wrote: > > on Sun May 01 2016, Xiaodi Wu wrote: > > > On Sun, May 1, 2016 at 7:01 PM, Dave Abrahams via swift-evolution > > wrote: > > > > on Sun May 01 20

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

It's a bad habit of mine, I guess, to err on the side of suggesting conservative changes on the assumption that it'll be maximally acceptable. If there's appetite for a more serious renaming, and as you say these are considered relatively rarely used, then it's a world of possibility! We could do

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I like it, but how do you accommodate sizeofValue, etc? On Mon, May 2, 2016 at 11:46 Dave Abrahams wrote: > > on Sun May 01 2016, Xiaodi Wu wrote: > > > It's a bad habit of mine, I guess, to err on the side of suggesting > conservative > > changes on the assumption that it'll be maximally accept

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

Well, I mean, it's not as though you invented them just for Swift. It's possible to evaluate sizeof an instance in C, C++, C#, D, Python, Rust... Removing this facility from Swift is a whole nother discussion from renaming. On Mon, May 2, 2016 at 3:11 PM, Dave Abrahams via swift-evolution < swift

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

Maybe one minimalist approach could be to have these take two arguments as though it's an infix operator where one of lhs or rhs is Void: T.++(&value, ()) //postfix T.++((), &value) // prefix On Mon, May 2, 2016 at 15:56 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on

Re: [swift-evolution] [Proposal] Improving operator requirements in protocols

On Mon, May 2, 2016 at 4:24 PM, Tony Allevato wrote: > On Mon, May 2, 2016 at 2:01 PM Xiaodi Wu wrote: > >> Maybe one minimalist approach could be to have these take two arguments >> as though it's an infix operator where one of lhs or rhs is Void: >> >> T.++(&value, ()) //postfix >> T.++((), &v

<    5   6   7   8   9   10   11   12   13   14   >