[Pitch] Expanded type category constraints


(Russ Bishop) #1

Do we already have a proposal for expanding constraints to support categories beyond class? I am guessing this might have ABI stability concerns, or at least library resilience concerns.

If so and no one else has tackled it I’m happy to write up a proposal. There are only a couple that I know of:

valuetype
Only struct and enum types would satisfy this constraint.

valuetype(pure)
A struct or enum that contain no reference types at all. The only reason to add this would be allowing certain optimizations, though the way existentials work today I’m not sure if this is even possible because the calls to value witnesses need to be emitted anyway.

functiontype
A function type. This doesn’t have much use today but eventually we could expand this to support reflecting the number and type of arguments, dynamically invoking, etc.

If there aren’t any ABI or resilience concerns then we can shelve it. I created https://bugs.swift.org/browse/SR-3056 to track the idea in either case.

Russ


(David Sweeris) #2

Do we already have a proposal for expanding constraints to support categories beyond class? I am guessing this might have ABI stability concerns, or at least library resilience concerns.

If so and no one else has tackled it I’m happy to write up a proposal. There are only a couple that I know of:

valuetype
Only struct and enum types would satisfy this constraint.

valuetype(pure)
A struct or enum that contain no reference types at all. The only reason to add this would be allowing certain optimizations, though the way existentials work today I’m not sure if this is even possible because the calls to value witnesses need to be emitted anyway.

functiontype
A function type. This doesn’t have much use today but eventually we could expand this to support reflecting the number and type of arguments, dynamically invoking, etc.

I think "valuetype(pure)" would make a good starting point for some stuff. It depends on what exactly "pure" means and whether there are other adjectives we can use.

There are (at least potential) optimizations whose name and exact definition are unclear to me. For example, does "pure" also imply that equality can be checked just by comparing the bits? Because that would exclude, say, a 1's complement integer type because they inherently have two bit patterns for 0, even though such a type would meet the definitions of "pure" that usually get suggested.

The topic of supporting a "pure" <noun> has come up a few times before, and it seems like they never go anywhere because of a) too many differing views on what "pure" actually means, and b) a reluctance to support additional adjectives ("reallypure", or whatever) to specify which definition of "pure" is intended.

I suspect that this is purely a language barrier issue... (See what I did there? Aw yeah... :grin:) Does anyone know of an online resource that explains graduate/phd-level computer science terms which are still under active research?

If there aren’t any ABI or resilience concerns then we can shelve it. I created https://bugs.swift.org/browse/SR-3056 to track the idea in either case.

I keep losing track of what exactly constitutes "ABI stability and resilience". I'm pretty sure someone posted some guidelines on the matter, but I forgot to bookmark it.

- Dave Sweeris, who swears he's really not trying to drag every thread off-topic

···

On Oct 26, 2016, at 20:56, Russ Bishop via swift-evolution <swift-evolution@swift.org> wrote:


(Brent Royal-Gordon) #3

ABI stability can generally be thought of as "anything that affects how APIs **that exist today** are represented in machine code". That includes features which will lead to binary-incompatible standard library redesigns, which is why we're working on things like conditional conformance.

I don't think a feature like this would qualify unless there are standard library interfaces we would redesign to use the new constraints.

···

On Oct 27, 2016, at 4:15 AM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

I keep losing track of what exactly constitutes "ABI stability and resilience"

--
Brent Royal-Gordon
Architechies