Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-3056] expand constraint categories #45646

Open
swift-ci opened this issue Oct 27, 2016 · 1 comment
Open

[SR-3056] expand constraint categories #45646

swift-ci opened this issue Oct 27, 2016 · 1 comment
Labels
compiler The Swift compiler in itself feature A feature request or implementation generic constraints Feature → generics: generic constraints generics Feature: generic declarations and types

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-3056
Radar None
Original Reporter russ (JIRA User)
Type New Feature
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels New Feature
Assignee None
Priority Medium

md5: 3f1fca16fc825fade00e0b7d42a56a27

Issue Description:

Copying this here from swift-evolution to keep track of it. This may or may not be in-scope for Swift 4.

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.
@belkadan
Copy link
Contributor

While this is certainly something that affects the language and backwards-deployment of libraries, I don't think it's actually a resilience concern. There may be plenty of language features we add that make your library not importable with an older compiler. The run-time behavior shouldn't be affected.

(Yes, it does mean that you can't retroactively add constraints where they should be necessary.)

The notion of "valuetype(pure)" is closer to what we're calling a "performance assertion" in the Library Evolution document. http://jrose-apple.github.io/swift-library-evolution/#other-promises-about-types

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis added feature A feature request or implementation generics Feature: generic declarations and types generic constraints Feature → generics: generic constraints and removed new feature labels Mar 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself feature A feature request or implementation generic constraints Feature → generics: generic constraints generics Feature: generic declarations and types
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@belkadan @swift-ci @AnthonyLatsis