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

[Feature Request] Constrained[False], or alternative, should not cause a return expected error #2547

Open
1 task done
Benny-Nottonson opened this issue May 6, 2024 · 1 comment
Labels
enhancement New feature or request mojo-repo Tag all issues with this label mojo-stdlib Tag for issues related to standard library

Comments

@Benny-Nottonson
Copy link

Review Mojo's priorities

What is your request?

Example Code

fn expand_type[Type: DType]() -> DType:
    @parameter
    if Type.is_floating_point():
        return DType.float64
    elif Type.is_signed():
        return DType.int64
    elif Type.is_integral():
        return DType.uint64
        
    constrained[False, "Type must be numeric"]()

The following code should NOT cause a "return expected at end of function with results" compilation error.

Along with this, there should really just be unreachable.

What is your motivation for this change?

If Mojo is allowing compile time verification of inputs to a function, it makes sense that extra code to return an invalid value should not be required, as the code added can by nature never run.

Any other details?

No response

@Benny-Nottonson
Copy link
Author

Messed up the PR a few times but it's done now

@ematejska ematejska added mojo-repo Tag all issues with this label and removed mojo-repo Tag all issues with this label labels May 6, 2024
@ematejska ematejska added the mojo-stdlib Tag for issues related to standard library label May 7, 2024 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request mojo-repo Tag all issues with this label mojo-stdlib Tag for issues related to standard library
Projects
None yet
Development

No branches or pull requests

2 participants