Fix Issue 21279 - cast expression between integer types is not defined

[ntrel]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @ntrel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21279	normal	cast expression between integer types is not defined

[schveiguy]

The two paragraphs seem to be overlapping in what they are specifying.

Both statements talk about signed values. I'm not exactly sure what the need for the second paragraph is.

[schveiguy]

This is somewhat of a bad example, because ubyte doesn't need a cast for byte.

[ntrel]

Yes, byte f = e; works implicitly. But I'm hoping there will be a warning or error for that eventually. So I think it's good practice to cast when the values might not fit.

[schveiguy]

The point I'm making is that there is no special rule for casting, as this implies.

[schveiguy]

Now that I'm looking for it, I also don't see anything in the spec on implicit conversions between types for assignment! Though it hints at it in the example here: https://dlang.org/spec/type.html#usual-arithmetic-conversions

[ntrel]

@schveiguy I have changed these to implicit conversions. I think it's OK to keep them under the cast docs as the first floating point example is also implicit conversions, not casts.

[ntrel]

Both statements talk about signed values. I'm not exactly sure what the need for the second paragraph is.

The first paragraph is about truncating to a smaller type. The first example shows this can flip the sign even when the source and target are both signed. The second paragraph is about differing signedness of source and target types.