rather than suggesting it's the semantic foundation of implicit
conversions.
The lossless + semantics-preserving rules should be sufficient to
identify what an implicit conversion does.

unsafe_as -> assume_as.

zygoloid marked this pull request as ready for review

September 25, 2021 00:44

Co-authored-by: Geoff Romer <gromer@google.com>

Co-authored-by: josh11b <josh11b@users.noreply.github.com>

right place.

This isn't an alternative; it's complementary to the current proposal.

zygoloid deleted the proposal-as-expressions branch

March 11, 2022 01:02

chandlerc pushed a commit that referenced this pull request

Jun 28, 2022

This proposal provides an `as` expression for casting. This supports implicit conversions plus some safe and unsurprising conversions that we do not support implicitly:
* lossy but fully defined conversions to floating-point types
* conversion from `bool` to integer types
* conversion between adaptors and their adapted type, and more generally between compatible types
This facility can be extended by implementing the `As(TargetType)` interface for a type.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>

Merged

Closed

Merged

zygoloid added a commit to zygoloid/carbon-lang that referenced this pull request

May 28, 2026

Implement support for floating-point <-> integer type conversions as
described in carbon-language#820 and carbon-language#845, extended to support `unsafe as` conversions
for the conversions that can't be expressed as either implicit
conversions or `as` conversions.
One tricky part here is conversions from floating-point literals to
integer types. Such literals may have both a very large mantissa and a
corresponding somewhat large negative exponent, and still produce a
result that is in the range of values that a small integer type can
represent. In order to support that while avoiding building very large
2^N or 10^N constants in general, we first compute a conservative
approximation of the number of bits necessary to represent the integer
result, with an early exit if the number is either definitely too large
or definitely zero. The remaining cases have a reasonable bound on the
size of integer necessary to compute the base^exponent multiplicand.
Assisted-by: Gemini via Antigravity

zygoloid added a commit to zygoloid/carbon-lang that referenced this pull request

May 29, 2026

Implement support for floating-point <-> floating-point type conversions
as described in carbon-language#820 and carbon-language#845. Value-preserving conversions are
implicit; narrowing conversions require explicit `as`.
Assisted-by: Gemini via Antigravity

Merged

github-merge-queue Bot pushed a commit that referenced this pull request

Jun 3, 2026

Implement support for floating-point <-> integer type conversions as
described in #820 and #845, extended to support `unsafe as` conversions
for the conversions that can't be expressed as either implicit
conversions or `as` conversions.
One tricky part here is conversions from floating-point literals to
integer types. Such literals may have both a very large mantissa and a
corresponding somewhat large negative exponent, and still produce a
result that is in the range of values that a small integer type can
represent. In order to support that while avoiding building very large
2^N or 10^N constants in general, we first compute a conservative
approximation of the number of bits necessary to represent the integer
result, with an early exit if the number is either definitely too large
or definitely zero. The remaining cases have a reasonable bound on the
size of integer necessary to compute the base^exponent multiplicand.
Assisted-by: Gemini via Antigravity

zygoloid added a commit to zygoloid/carbon-lang that referenced this pull request

Jun 4, 2026

Implement support for floating-point <-> floating-point type conversions
as described in carbon-language#820 and carbon-language#845. Value-preserving conversions are
implicit; narrowing conversions require explicit `as`.
Assisted-by: Gemini via Antigravity

pull Bot pushed a commit to SammyEnigma/carbon-lang that referenced this pull request

Jun 4, 2026

Implement support for floating-point <-> floating-point type conversions
as described in carbon-language#820
and carbon-language#845.
Value-preserving conversions are implicit; narrowing conversions require
explicit `as`.
Assisted-by: Gemini via Antigravity