Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

on Sat Jan 28 2017, Brent Royal-Gordon wrote: >> On Jan 28, 2017, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >> The way to handle Deque is to add this requirement to Collection when >> we get the language features to express it: >> > >> protocol Collection { >> >>assoc

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

on Sun Jan 29 2017, Dave Abrahams wrote: > on Sat Jan 28 2017, Brent Royal-Gordon wrote: > >>> On Jan 28, 2017, at 11:48 AM, Dave Abrahams via swift-evolution >>> > wrote: >>> >>> The way to handle Deque is to add this requirement to Collection when >>> we get the language features to expres

Re: [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

> On Jan 24, 2017, at 12:28 PM, Daniel Dunbar via swift-evolution > wrote: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md I am in serious need of this feature for one of my projects, and the design looks pretty good to me. +1. -- B

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution > wrote: > > Protocol-oriented integers (take 2) > > • Proposal: SE- > • Authors: Dave Abrahams, Maxim Moiseev > • Review Manager: TBD > • Status: Awaiting review > • Bug: SR-3196 > • Previo

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 6:02 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Protocol-oriented integers (take 2) > > > > • Proposal: SE- > >

Re: [swift-evolution] protocol-oriented integers (take 2)

Shouldn’t “Number” be reserved for a foundation type similar to NSNumber? Or would this protocol actually serve that purpose? I was planning to ask for a value type similar to NSNumber in phase 2. I built one for my own code (a struct around an enum which can be Int, Decimal, Rational, or Rat

Re: [swift-evolution] protocol-oriented integers (take 2)

I think these protocols + generics should cover most such use cases, no? On Sun, Jan 29, 2017 at 06:57 Jonathan Hull wrote: > Shouldn’t “Number” be reserved for a foundation type similar to NSNumber? > Or would this protocol actually serve that purpose? > > I was planning to ask for a value typ

[swift-evolution] Subclass Existentials

Hello, As promised, I wrote the first draft of a proposal to add class requirements to the existential syntax. Please let me know what you think. https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/-subclass-existentials.md Regards, David. Existentials for class

Re: [swift-evolution] A case for postponing ABI stability

I have to assume that was sarcasm. The Release to Release Binary Compatibility with SOM (http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/doc&file=R2R_SOM.zip) paper includes the following footnote: "We exclude Microsoft’s COM [14] because it is an interface model, not an object model and it’s

Re: [swift-evolution] Subclass Existentials

+1 on including concrete types, this is currently a gaping hole in the language. -100 on requiring the concrete type to be first. If I want to specify the types alphabetically, grouped by module, or any other way I choose, why should I not be allowed to do so? The compiler can warn on redundancie

Re: [swift-evolution] Subclass Existentials

Hi David, This looks like a great start. One thing we should consider is whether we tie this proposal so tightly to classes or whether it might be better to call these supertype constraints. The feature might also be useful for value types if / when Swift gets value subtyping. One enhancemen

Re: [swift-evolution] Subclass Existentials

As Matthew mentioned, the rules can certainly later be relaxed, but given that this proposal has the compiler generating fix-its for subclasses in second position, is there a reason other than stylistic for demanding MyClass & MyProtocol instead of MyProtocol & MyClass? From a naive perspective, i

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 13, 2017, at 12:47, Max Moiseev via swift-evolution > wrote: > DoubleWidth > The DoubleWidth type allows to create wider fixed-width integer types from > the ones available in the standard library. > > Standard library currently provides fixed-width integer types of up to 64 > bits.

Re: [swift-evolution] protocol-oriented integers (take 2)

Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, but the performance hit for any useful computation over a large array would probably tilt heavily in favor of plain 64-bit integers. What's your use case for such a 40-bit type? And is it common enough to justify such a fac

Re: [swift-evolution] Subclass Existentials

Thanks for writing this proposal David. > On Jan 29, 2017, at 10:13, Xiaodi Wu via swift-evolution > wrote: > > As Matthew mentioned, the rules can certainly later be relaxed, but given > that this proposal has the compiler generating fix-its for subclasses in > second position, is there a

Re: [swift-evolution] Subclass Existentials

The "class comes first" requirement made more sense when the proposed syntax was still "Any", intentionally mirroring how the superclass and conformances are declared on a class declaration (the archives contain more detailed arguments, both pro and con). Now that the syntax is "T & U & V", I a

Re: [swift-evolution] Subclass Existentials

Cool. Another avenue of improvement here is relaxing the single-class spelling rule for the sake of composing typealiases. As Matthew mentioned, if I have class Base and typealiases Foo = Base & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & Bar. It'd be nice to go one step fur

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Jonathan Hull wrote: > Shouldn’t “Number” be reserved for a foundation type similar to > NSNumber? Or would this protocol actually serve that purpose? I don't think so. What is the purpose of NSNumber? I always viewed it as being, approximately, a box that allows us to pu

Re: [swift-evolution] Subclass Existentials

Sent from my iPad > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution > wrote: > > Cool. Another avenue of improvement here is relaxing the single-class > spelling rule for the sake of composing typealiases. > > As Matthew mentioned, if I have class Base and typealiases Foo = Base

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: > > Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, > but the performance hit for any useful computation over a large array would > probably tilt heavily in favor of plain 64-bit integers. What's your use case > for suc

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Cool. Another avenue of improvement here is relaxing the single-class > spelling rule for the sake of composing

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris wrote: > > On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: > > Hmm, interesting. I might be tempted to use a 40-bit type for large > arrays, but the performance hit for any useful computation over a large > array would probably tilt heavily in favor of

Re: [swift-evolution] Subclass Existentials

I think it makes sense to require class bounds to be first, for the same reason they must be first in. Lass inheritance clauses: to encourage consistency and make it more clear when some type has an ambiguous name (which shouldn't happen, but...) -Chris > On Jan 29, 2017, at 9:03 AM, Kevin Nat

Re: [swift-evolution] Subclass Existentials

Sorry, I meant to say for the same reason they are required to be first in class inheritance/conformance clauses. -Chris > On Jan 29, 2017, at 12:14 PM, Chris Lattner wrote: > > I think it makes sense to require class bounds to be first, for the same > reason they must be first in. Lass inher

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Cool. Anothe

Re: [swift-evolution] Subclass Existentials

+1 on the proposal overall. You might want to clarify the writing wrt source compatibility though. The new syntax and type system mechanics should work in Swift 3 mode, it is just the importer change that must be conditionalized. -Chris > On Jan 29, 2017, at 8:39 AM, David Hart via swift-evol

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org>

Re: [swift-evolution] Subclass Existentials

Can I say that I dearly miss the old Any<> syntax? Oh well... Sent from my iPhone > On 29 Jan 2017, at 18:41, Austin Zheng via swift-evolution > wrote: > > The "class comes first" requirement made more sense when the proposed syntax > was still "Any", intentionally mirroring how the superclas

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 12:13, Xiaodi Wu wrote: > >> On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris wrote: >> >>> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: >>> >>> Hmm, interesting. I might be tempted to use a 40-bit type for large arrays, >>> but the performance hit for any useful computat

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson >

Re: [swift-evolution] Subclass Existentials

+1 on the proposal, but this shows why mixing classes and protocols like so just confuses things... classOrStructOrThingyOhIMissYouNSProxy Gave the separation we needed, but then withGenerics this becomes a bit worse to handle... Sent from my iPhone > On 29 Jan 2017, at 17:03, Kevin Nattinge

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 29, 2017 at 2:30 PM, David Sweeris wrote: > > On Jan 29, 2017, at 12:13, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:03 PM, David Sweeris > wrote: > >> >> On Jan 29, 2017, at 10:36, Xiaodi Wu wrote: >> >> Hmm, interesting. I might be tempted to use a 40-bit type for large >> arr

[swift-evolution] extending typealiases

In Swift 3.1, I was happy to see that we can now extend types with concrete constraints. I think one other feature which fits nicely with this new capability would be extending typealiases, like this: typealias Vector = Array extension Vector { ... } Which currently doesn't compile due to

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > wrote: > >> >> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: >> >> On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson >> wrote: >> >>

Re: [swift-evolution] extending typealiases

Seems totally fair to add if someone wants to devote the time and effort to implement it, but also easily worked around for the moment and therefore (IMO) not a pressing issue. On Sun, Jan 29, 2017 at 3:03 PM, Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote: > In Swift 3.1,

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson >

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson >

[swift-evolution] [Proposal] Add Array binary search to the standard library

Hi guys, I know this topic is probably out of scope for Swift 4 and a proposal was already rejected for Swift 3, but I’d like to share my two cents on this as I just wrote a SortedArray class with support for binary search in my open source library HandySwift. You can see my classes current imp

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 3:05 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson > wrote: > >> >> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: >> >> On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson >> wrote: >> >>

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 3:24 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson > wrote: > >> >> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu wrote: >> >> On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson >> wrote: >> >>

Re: [swift-evolution] Subclass Existentials

Hi Matthew, I’ll reply to this post, because it allows me to discuss a few of the points in the discussion, but I’ve read the whole discussion. > On 29 Jan 2017, at 18:30, Matthew Johnson wrote: > > Hi David, > > This looks like a great start. > > One thing we should consider is whether we t

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson >

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 4:01 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the > points in the discussion, but I’ve read the whole discussion. > > On 29 Jan 2017, at 18:30, Matthew Johnson

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:01 PM, David Hart wrote: > > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the points > in the discussion, but I’ve read the whole discussion. > >> On 29 Jan 2017, at 18:30, Matthew Johnson > > wrote: >

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 29, 2017, at 4:01 PM, David Hart wrote: > > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the > points in the discussion, but I’ve read the whole

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:48 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jan 29, 2017, at 4:01 PM, David Hart > > wrote: >> >> Hi Matthew, >> >> I’ll reply to this po

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

Hi Cihat, Thanks for diving in here! For reference, here's the last thing I said about this topic (IIRC): https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016729.html Also https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift.gyb#L679 Note: the comm

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 6:00 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 4:48 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jan 29, 2017, at 4:01 PM, David Hart wrote: >> >> Hi Matthew, >> >>

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Brent Royal-Gordon wrote: >> On Jan 13, 2017, at 12:47 PM, Max Moiseev via swift-evolution >> wrote: >> >> Protocol-oriented integers (take 2) >> >> • Proposal: SE- >> • Authors: Dave Abrahams, Maxim Moiseev >> • Review Manager: TBD >> • Status: Aw

Re: [swift-evolution] extending typealiases

> On Jan 29, 2017, at 1:03 PM, Matt Whiteside via swift-evolution > wrote: > > In Swift 3.1, I was happy to see that we can now extend types with concrete > constraints. I think one other feature which fits nicely with this new > capability would be extending typealiases, like this: > > typ

Re: [swift-evolution] Subclass Existentials

This is a nice generalization of the existing protocol composition syntax. Implementation might get a little tricky — this touches a lot of things, such as inheritance clauses, constraints in generic signatures, and casts. It would require thorough testing. There are also a few odd corner cases

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson > > wrote: >> >>> On Jan 29, 2017, at 3:24 P

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 29, 2017, at 7:02 PM, Dave Abrahams via swift-evolution > wrote: > >>> var popcount: Int { get } >> >> I'm not super-fond of this name; I assume it's a term of art, but it's >> a pretty obscure one. Maybe `numberOfOnes`? `onesWithin`? > > Yes, the rationale is that it's a term of art

Re: [swift-evolution] protocol-oriented integers (take 2)

I share your concern about trailingZeros and leadingZeros; those could probably be improved as trailingZeroBits and leadingZeroBits. The terms of art there, ctz ("count trailing zeros") and clz, are a bit cryptic but perhaps also fine if ulp is acceptable for FloatingPoint. On Sun, Jan 29, 2017

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 29 2017, Brent Royal-Gordon wrote: >> On Jan 29, 2017, at 7:02 PM, Dave Abrahams via swift-evolution >> wrote: >> var popcount: Int { get } >>> >>> I'm not super-fond of this name; I assume it's a term of art, but it's >>> a pretty obscure one. Maybe `numberOfOnes`? `onesWit

Re: [swift-evolution] Strings in Swift 4

I prefer c[i...] After all, why should it mean c[i...c.endIndex] and not c[i...c.lastIndex]? With the latter interpretation it is not just typographically nicer but also consistent. -Thorsten Am 23.01.2017 um 00:40 schrieb Chris Lattner via swift-evolution : >> In my experiments with intro