# 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:** 31

<div class="post-metadata">

**Author:** ![comex](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/comex/32/2587_2.png) [@comex](https://internals.rust-lang.org/u/comex)\
**Post date:** [February 6, 2018, 12:20am UTC](https://internals.rust-lang.org/t/pre-rfc-const-function-arguments/6709/31 "2018-02-06T00:20:21Z")

</div>

As an interesting data point:

Swift doesn’t support const generics, but even for type parameters, it has a mechanism specifically to avoid the need for explicit function specialization (i.e. turbofish), which it doesn’t support at all.

For example, to do the equivalent of `transmute`, you can write:

```
let transmuted = unsafeBitCast(foo, to: Int32.self)

```

The `unsafeBitCast` function is declared as

```
public func unsafeBitCast<T, U>(_ x: T, to type: U.Type) -> U

```

This works because `Int32.Type` is a singleton type with `Int32.self` as the sole instance (and that works for any type). However, it requires some special-casing, because `T.Type` looks like an associated type, but normally you can’t do type inference backwards from an associated type to the base type. (Associated types in Swift have similar semantics as in Rust.) And for that matter, I find it a bit strange: why can’t you just write `to: Int32`? In Rust, the reason you can’t just write a type in expression position is to avoid parser ambiguities with angle brackets, but adding `.self` at the end doesn’t help with that (and Swift has a different solution to the angle bracket issue).

But anyway, you can see how it’s nice to put generic parameters into the regular flow of function arguments, allowing for a more natural ordering. Swift probably benefits more from this than Rust would, due to its pervasive use of argument labels - i.e. `cast(value, to: Type)` clearly flows better than `cast<Type>(value)`, but you couldn’t say the same for `cast(value, Type)`. Still - getting back on topic - when it comes to _value_ parameters (const generics), I think there are more cases where it would be useful.

---

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