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

[SR-13313] Redundant Int casting for Array Index #55753

Closed
swift-ci opened this issue Jul 29, 2020 · 2 comments
Closed

[SR-13313] Redundant Int casting for Array Index #55753

swift-ci opened this issue Jul 29, 2020 · 2 comments
Labels
casting Feature: explicit casting (is, as, as? and as!) compiler The Swift compiler in itself feature A feature request or implementation improvement type checker Area → compiler: Semantic analysis will not do Resolution: Will not be worked on

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-13313
Radar None
Original Reporter srinikhil07 (JIRA User)
Type Improvement
Status Closed
Resolution Invalid
Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Improvement, DiagnosticsQol, TypeChecker
Assignee None
Priority Medium

md5: e2a8738d44ee72e782637ef0cb70b37d

Issue Description:

Hi,

var hash = Array.init(repeating: 0, count: 26)   
hash[Character("B").asciiValue! - Character("A").asciiValue!] = 1  

The above code snippet produces error

cannot convert value of type 'UInt' to expected argument type 'Int'

To solve the above error, I had to cast the index expression to Int

hash[Int(Character("B").asciiValue! - Character("A").asciiValue!)] = 1

Since any UInt covers

  1. only positive integers,

  2. is a subset of Int (which also includes negative numbers)

  3. In a way UInt is safe for Array as it omits negative range thereby preventing array index out of bounds crashes,

Isn't type checking UInt for Array index redundant?

I believe we can allow UInt variants for Array indices without any problems.

Thanks,

Nikhil.

@theblixguy
Copy link
Collaborator

From TSPL:

> Use UInt only when you specifically need an unsigned integer type with the same size as the platform’s native word size. If this isn’t the case, Int is preferred, even when the values to be stored are known to be nonnegative. A consistent use of Int for integer values aids code interoperability, avoids the need to convert between different number types, and matches integer type inference, as described in Type Safety and Type Inference.

@swift-ci
Copy link
Collaborator Author

Comment by Nikhil (JIRA)

@theblixguy

Yes, I get it now. Thank you for the explanation.

Will also do a more exhaustive search before raising it here in future.

We can close this.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal added diagnostics QoI Bug: Diagnostics Quality of Implementation and removed DiagnosticsQol labels Apr 26, 2022
@AnthonyLatsis AnthonyLatsis added the compiler The Swift compiler in itself label Dec 13, 2022
@AnthonyLatsis AnthonyLatsis added will not do Resolution: Will not be worked on swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented feature A feature request or implementation casting Feature: explicit casting (is, as, as? and as!) and removed Foundation swift evolution implemented Flag → feature: A feature that was approved through the Swift evolution process and implemented diagnostics QoI Bug: Diagnostics Quality of Implementation labels Jan 17, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
casting Feature: explicit casting (is, as, as? and as!) compiler The Swift compiler in itself feature A feature request or implementation improvement type checker Area → compiler: Semantic analysis will not do Resolution: Will not be worked on
Projects
None yet
Development

No branches or pull requests

4 participants