Is there any disadvantage of labeling a function const?

For functions that can be labelled as const, is there any disadvantage of labelling it as const ?

It's an API contract. You should probably think about it like implementing Copy for a type. Do you want to guarantee the function will be const "forever" ?

9 Likes

To elaborate a little: marking function as const is indeed by itself free (when possible), but removing the constness is a breaking change.

4 Likes

Yeah, but I see this as a feature, not a bug. Removing const/Copy and getting a compiler error because something else depended on it -- I see this as a good thing.

1 Like

As explained, removing const is a breaking change. As in, it breaks other peoples' code (not yours.) It's obviously not a good thing to do that... So it seems like you're trying to spin that into a claim that const is good because it forces you to keep it... but const is entirely optional in the first place. If you don't use it, you won't be forced to keep it either. It can only cause a break if you use it. I.e., the only upside to const is if you need compile-time evaluation. It literally provides only downsides if you're not using it for that purpose.

When you're the final user, i.e. you're creating a binary - yes, that's surely good. The problem arises only when you're writing a library, which can be used by someone else's binary.

3 Likes

I'm not trying to spin anything. You are assuming that I am releasing a public library, which I am not.

Your fundamental assumption is false.

2 Likes

As long as Enum/Structs are small (<= 32 bytes), I generally mark them #[derive(copy)] by default. Then, if I add a Rc, a Vec, or something else that makes it no longer Copy-able, I remove the Copy.

I actually like seeing #[derive(Copy)] for two reasons: (1) I don't have to deal with x.clone() and (2) I know I don't have to worry abut a "drop chain stack overflow" since there is no drop handler.

No. I fix it by removing #[derive(Clone)] from structs/enums that are now no longer copy-able.

You have a very bad habit of making incorrect assumptions as if I'm incompetent, then attacking that strawman.

If, in your eyes, I am so technically incompetent, why not spend your time on something more useful than criticizing strawmans ?

1 Like

I am not entirely sure if labelling a function const generates more efficient asm. I don't usually label functions const unless I'd actually be using it elsewhere. I have usually found it a greater headache to keep a function const after several refactors. On the other hand, if you anticipate that the constness will be used, I think it's worth it.

It does not. Whether a function is const fn is not currently used for optimization in any manner. That's not to say it won't be in the future.

1 Like

Moderator note: People can solve problems without publishing libraries on crates.io, and even exploratory programming without any immediate goal at all can be valuable. If you aren’t interested, that’s fine. Don’t participate.

2 Likes

This approach doesn't make much sense to me.

When I decide whether a type should be Copy, size plays a role, but its one of the less-important factors. To me, the type's role within the API is far more important. For example, I use non-Copy, zero-sized structs to act as singleton tokens. I can't really imagine arbitrarily marking a type Copy only to come back and remove it later.

I think that's what @erelde, @Cerber-Ursi and @skysch are trying to say. Whether a type is Copy or a function is const depends on its role in the API. Even if no one will depend on your code, the decision is still an essential part of the API design.

10 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.