Hacker News Reader

Comment by WhereIsTheTruth | Hacker News Reader

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...

View on HN

> 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.

Putting using statements inside small functions is the opposite of ehancing readbility.

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.

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.

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

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.

Reply on news.ycombinator.com