# pre-RFC \`const\` function arguments

**URL:** <https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709>\
**Category:** language design\
**Created:** [February 5, 2018, 4:58pm UTC](https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709 "2018-02-05T16:58:38Z")\
**Posts on this page:** 1\
**Showing post:** 25

<div class="post-metadata">

**Author:** ![gnzlbg](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gnzlbg/32/3858_2.png) [@gnzlbg](https://internals.rust-lang.org/u/gnzlbg)\
**Post date:** [February 5, 2018, 11:34pm UTC](https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709/25 "2018-02-05T23:34:13Z")

</div>

> [@mark-i-m](#):
>
> beginners who don’t understand const-generics won’t understand structural equality

Good point, this is a problem that `const` variables do not have. This reinforces the idea that `const` variables are not equivalent to `const`-function arguments (which are equivalent to `const` parameters). Having said this, the error messages for this do not need to mention structural equality or any other technical terms. `const`-generics is going to have these problems and if we can have good error messages there we can have them here as well. This is important because RFC2000 makes it very clear floating point values will _never_ be usable in `const` generics because they are not reflexive, so I would guess that floating point types in particular will probably get their own custom error message because this is a common error to make.

* * *

@leonardo From the RFC2000:

> This restriction can be analogized to the restriction on using type variables in types constructed in the body of functions - all of these declarations, though private to this item, must be independent of it, and do not have any of its parameters in scope.

---

_[View the full topic](https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709)._