Post #2598500

2023-03-19 09:15 UTC

@slomo@toot.cat Somewhat counterintuitively, keeping the order unspecified can lead to easier-to-reason about code in some cases, because any attempts to depend on a specific order must be a bug. For a lot of calls LTR is “obvious” but this isn’t always true.

Replies (2)

@saagar@federated.saagarjha.com 2023-03-19 09:17

@slomo@toot.cat Take, for example, a language that allows both specifying default argument expressions (e.g. Swift) and reordering parameters by name (e.g. Python). Combining both of these features, which is not all that unreasonable, can “break” LTR for either the caller or callee.

Open ##2598501
@slomo@toot.cat 2023-03-19 09:20

@saagar@federated.saagarjha.com Right, so why not a) specify it (so at least the order of the side-effects that don't affect each other is not random), and b) disallow code where the order actually matters (side effects of one part of the expression affecting another one)? For optimizations, I'm still waiting for an example where this actually allows any kind of useful optimization that is not possible otherwise. If you have one, please let me know 🙂 That both gcc and clang rely on one fixed order seems like a hint that there is actually not much opportunity for using this for optimizations.

Open ##2598503