Skip to content

Do not require explicit casting for small comptime literals that can fit in a typed integer #747

Description

@tiehuis

Currently we emit an error if we attempt to pass a comptime literal to be formatted.

printf("{}", 5);
error: parameter of type '(integer literal)' requires comptime

This example requires that the 5 be explicitly cast to an integer of specified size before we can actually print.

printf("{}", u64(5));

Often, we just want any readable value we can so we could instead check whether the literal fits into the range of a specific large integer type (i.e. u64) and cast within the printf routine.

This proposal suggest doing automatic casting within printf in order to simplify and make code clearer. Also note we have a similar issue for floats, however casting/narrowing there is likely a bit more nuanced in respect to preserving precision.

The following would compile and work if accepted.

printf("{}", 5);

Activity

  1. added
    proposalThis issue suggests language modifications. If it also has the "accepted" label then it is planned.
    on Feb 7, 2018
  2. zesterer commented on Feb 7, 2018

    @zesterer

    Why not simply consider the integer to have a type equal to the smallest type capable of representing this integer when passed through a function call? 5 would assume the type u3 (or u8 if it's more useful internally for the compiler) when passed into the variadic component of fmt.format.

    The advantage of this is that this issue is fixed across the breadth of the language, rather than just the narrow case of fmt.format in std.

  3. andrewrk commented on Feb 7, 2018

    @andrewrk
    Member

    See also #137

  4. andrewrk commented on Feb 7, 2018

    @andrewrk
    Member

    I think this can be fixed without casting number literals (soon to be renamed to comptime_int or maybe even just int #556)

    I think there's a place in the compiler where we disallow an comptime int as a var args parameter, but we can remove this restriction.

  5. added this to the 0.3.0 milestone on Feb 7, 2018
  6. modified the milestones: 0.3.0, 0.4.0 on Feb 28, 2018
  7. modified the milestones: 0.4.0, 0.3.0 on Mar 12, 2018
  8. modified the milestones: 0.3.0, 0.4.0 on Jul 18, 2018
  9. modified the milestones: 0.4.0, 0.5.0 on Mar 20, 2019
  10. removed this from the 0.5.0 milestone on Sep 20, 2019
  11. 4 remaining items

  12. added this to the 0.8.0 milestone on Oct 9, 2020
  13. modified the milestones: 0.8.0, 0.9.0 on May 19, 2021
  14. modified the milestones: 0.9.0, 0.10.0 on Nov 20, 2021
  15. modified the milestones: 0.10.0, 0.11.0 on Apr 16, 2022
  16. modified the milestones: 0.11.0, 0.12.0 on Apr 9, 2023
  17. modified the milestones: 0.13.0, 0.12.0 on Jun 29, 2023
  18. modified the milestones: 0.14.0, 0.15.0 on Jan 25, 2025
  19. mlugg commented on Apr 29, 2026

    @mlugg
    Member

    This works today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedThis proposal is planned.proposalThis issue suggests language modifications. If it also has the "accepted" label then it is planned.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions