3 ms·

All that crap is the reason I never bother with enums in all these C like languages set_player_color(player, .RED); That should be the way to use them, i

All that crap is the reason I never bother with enums in all these C like languages set_player_color(player, .RED); That should be the way to use them, it's concise and typesafe set_color(Color::RED); Why repeat yourself? It's one of the things I love about Swift and Zig int main() { using enum ComputeStatus; ComputeStatus s = NotEnoughMemory; } now you have polluted the scope.. C++ have lost the plot.. they understood the issue, but they came up with a solution that's worse...

Lvl999Noob 2y ago
> now you have polluted the scope Actually they haven't. Using glob imports inside small functions can enhance readability without causing confusion. Otherwise any kind of aliasing and importing would be polluting the scope since they are bringing other items into your module without the full path.
- account42 2y ago
  Putting using statements inside small functions is the opposite of ehancing readbility.
  - consteval 2y ago
    I disagree, because the scope doesn't escape those functions and it can greatly reduce the amount of :: Usually in an entire codebase or a module there's a lot of competing, similar symbols. But in a function that's not the case, because they do something small. So there's no benefit to being more "explicit", because the function already states what it does. For example you might not want to use std::chrono. But in, say, a series of timing functions you really don't want to be writing std::chrono:monotonic_clock::now(), do you? You can just use a using and then just call now() or whatever.
jeroenhd 2y ago
It's obvious with Color, but when you deal with more complex stuff, code like computation_service.set_status(ComputeStatus::NotEnoughMemory); system.set_state(SystemState::Failure); is a lot clearer than computation_service.set_state(.NotEnoughMemory); system.set_state(.Failure); in my opinion. Both objects/structs/whatevers can have a state type of their own but the shorthand form does not indicate whether or not the two can be used interchangeably. As a workaround, you could rename the setter to set_computation_state and set_system_state but then you're just repeating yourself in a different manner that's not as precise.
- WhereIsTheTruth 2y ago
  Obviously, you should still have the choice to be verbose when the context requires it, pragmatism is the key In your example, to me, the value is obfuscated, I prefer conciseness, it's easier to read and it makes more sense Besides, it encourages developers to better name their variables/functions SwiftUI made me appreciate it more
- account42 2y ago
  I disagree about which one of your examples is clearer. The first has too much visual noise you need to parse before you can see what is going on.

Lvl999Noob 2y ago

> now you have polluted the scope Actually they haven't. Using glob imports inside small functions can enhance readability without causing confusion. Otherwise any kind of aliasing and importing would be polluting the scope since they are bringing other items into your module without the full path.

account42 2y ago
Putting using statements inside small functions is the opposite of ehancing readbility.
- consteval 2y ago
  I disagree, because the scope doesn't escape those functions and it can greatly reduce the amount of :: Usually in an entire codebase or a module there's a lot of competing, similar symbols. But in a function that's not the case, because they do something small. So there's no benefit to being more "explicit", because the function already states what it does. For example you might not want to use std::chrono. But in, say, a series of timing functions you really don't want to be writing std::chrono:monotonic_clock::now(), do you? You can just use a using and then just call now() or whatever.

jeroenhd 2y ago

It's obvious with Color, but when you deal with more complex stuff, code like computation_service.set_status(ComputeStatus::NotEnoughMemory); system.set_state(SystemState::Failure); is a lot clearer than computation_service.set_state(.NotEnoughMemory); system.set_state(.Failure); in my opinion. Both objects/structs/whatevers can have a state type of their own but the shorthand form does not indicate whether or not the two can be used interchangeably. As a workaround, you could rename the setter to set_computation_state and set_system_state but then you're just repeating yourself in a different manner that's not as precise.

WhereIsTheTruth 2y ago
Obviously, you should still have the choice to be verbose when the context requires it, pragmatism is the key In your example, to me, the value is obfuscated, I prefer conciseness, it's easier to read and it makes more sense Besides, it encourages developers to better name their variables/functions SwiftUI made me appreciate it more
account42 2y ago
I disagree about which one of your examples is clearer. The first has too much visual noise you need to parse before you can see what is going on.