You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #67792 it was suggested to file a new issue regarding any additional discussion, and it looks like the syntax for ~const is not finalized. In rust-lang/lang-team#162 and #102090, it still looks like ~const is still a placeholder keyword. I'd like to propose another syntax: where const
fntriple_add<T>(a:T,b:T,c:T) -> TwhereT:Add<Output=T>,
where const
T:constAdd<Output=T>,{
a + b + c
}
Like with normal trait bounds, we would add another where clause to functions that define when the function is const. In the previous example, there is a type bounds on T that always applies, followed by the declaration that triple_add is const if and only if the Add implementation is const.
While this looks a little verbose, where const allows for different bounds to permit const as well. If there was a ConstAdd trait that was always const, we could express the following instead:
fntriple_add<T>(a:T,b:T,c:T) -> TwhereT:Add<Output=T>,
where const
T:ConstAdd<Output=T>,{
a + b + c
}
This gives us flexibility in different how different the const bounds are expressed in the future, should we decide to expand or restrict it.
A trait could express const bounds as well in a similar way:
traitFoo<Other>where const
Other:constBar,{}
I think this form has a lot of benefits over the existing ~const:
where const is more familiar than ~const in my opinion: where adds bounds to the function, so its more intuitive that where const adds const bounds the the function.
It allows us to determine the inline representation later, if one is desired.
It better expresses that const is opt-in, without the const keyword in the front
It allows flexibility in how const bounds are expressed, in the way that other traits could express constness, as shown with the previous snippets.
It also gives a framework for keyword generics, e.g. with async:
fntriple_add<T>(a:T,b:T,c:T) -> TwhereT:Add<Output=T>,
where async
T:asyncAdd<Output=T>,{/* ... */}
We can restrict requirements if needed, such as requiring all where const clauses to be T: const Trait where Trait is defined in the where bound, and then later opening up to more free bounds.
It might be easier to implement in terms of rustdoc and rustc implementation, since it would be iterating on the where bounds. That being said, I'm not sure of this either.
To the best of my ability, I haven't seen any suggestion of this. Please let me know if I've missed anything.
The text was updated successfully, but these errors were encountered:
is not currently syntax, since we expect a where-clause bound after where instead of a semicolon. Not sure if you're proposing that also, but just wanted to note it.
Oops, nope, didn't mean to. Thanks for the heads-up.
edward-shen
changed the title
Alternative syntax suggestion for tilde keyword (~const): where const:
Alternative syntax suggestion for tilde keyword (~const): where constJan 18, 2023
The feature still exists, it's just not being used in the standard library, but it's gonna get reworked heavily anyways. I'm gonna close this -- if you want to brainstorm new ideas for conditionally const trait bounds, https://internals.rust-lang.org might be a better idea.
Uh oh!
There was an error while loading. Please reload this page.
In #67792 it was suggested to file a new issue regarding any additional discussion, and it looks like the syntax for
~const
is not finalized. In rust-lang/lang-team#162 and #102090, it still looks like~const
is still a placeholder keyword. I'd like to propose another syntax:where const
Like with normal trait bounds, we would add another
where
clause to functions that define when the function isconst
. In the previous example, there is a type bounds onT
that always applies, followed by the declaration thattriple_add
is const if and only if theAdd
implementation isconst
.While this looks a little verbose,
where const
allows for different bounds to permitconst
as well. If there was aConstAdd
trait that was alwaysconst
, we could express the following instead:This gives us flexibility in different how different the
const
bounds are expressed in the future, should we decide to expand or restrict it.A trait could express
const
bounds as well in a similar way:I think this form has a lot of benefits over the existing
~const
:where const
is more familiar than~const
in my opinion:where
adds bounds to the function, so its more intuitive thatwhere const
addsconst
bounds the the function.const
is opt-in, without theconst
keyword in the frontconst
bounds are expressed, in the way that other traits could expressconst
ness, as shown with the previous snippets.async
:where const
clauses to beT: const Trait
whereTrait
is defined in thewhere
bound, and then later opening up to more free bounds.To the best of my ability, I haven't seen any suggestion of this. Please let me know if I've missed anything.
The text was updated successfully, but these errors were encountered: