451–460 of 539 posts
Strongly-typed units and unit literals (e.g. 3mL, 10gal, 15m / 3s = 5m/s) AFAIK F# has these and that's about it
Earlier quoted context omitted.
Right, cause why let the language do it automatically when you can use a bug prone manual implementation?
If you can't correctly implement a circular buffer with mod (or 'and') then the language can't save you, nothing can.
Earlier quoted context omitted.
Interestingly, there was once a solid effort to add a try operator to Go. While the proposal was quite well received, upon closer inspection it was realized it would be essentially useless in the real world as, given how the rest of the language works, you almost never would want to simply early return with the value received. The data revealed that the vast majority of the code in the wild that the syntax sugar woul…
Is there a link to this discussion? This seems interesting. If I can’t make a call to a downstream service, or a file I’m trying to read doesn’t exist, or a s3 bucket 404’s, or almost any other “real world” error I can think of, the only (sane) way I can think of handling this is propagating the error down to the caller (and perhaps logging?) Do you mean to say that it is idiomatic in Go to handle errors by… doing so…
A big problem, among many, with doing that is that you leak implementation details out of the abstraction. If, to stick with your example, you have a function that helps you with reading files, the caller shouldn't care where the data is stored. Today it might be the local filesystem, tomorrow S3, and when you make that change nothing about the rest of the program should break.
But you can't count on the lower level functions using the same errors. As you suggest, a "a file I’m trying to read doesn’t exist" isn't represented as a "bucket 404", even though at a higher level they are the exact same thing. If you straight returned the "a file I’m trying to read doesn’t exist" error as you got it from the file API, now the caller is going to depend on that, and when you replace it with the S3 function that returns a "bucket 404" error, everything starts to break.
What you typically want to do is return a more generalized "not found" error that can remain stable regardless of specific implementation details. There are rare cases where you can get away with simply returning the value up the stack, but in the majority of cases you need to handle the error, either by doing something with it or returning a new error that is more useful to the caller. And, so, try becomes essentially unusable without the language taking a larger macro take on supporting such a feature.
Like the sibling comment points out, Rust does "from" conversion when using try (?) to try and avoid encountering the same fate.
Earlier quoted context omitted.
I would assume they're looking for a specific constant value.
grep '[0-9_]+'|sed 's/_//g'|grep
Earlier quoted context omitted.
I've only seen this proposed as a feature to help with template meta-programming (though it could also make similar sense in any dynamic language). There, it helps if a template can say `t.foo()`, and, with UFCS, can use that template with any t for which either `foo(t)` or `t.foo()` exist. In contrast, in C++ today, a template using `t.foo()` limits its own use only to types that have a foo() method, probably unnece…
What do you mean by “twice as many places”? And looking up definitions is a job for the language server.
And sure, the IDE/language server/other tooling can often help, but not always (e.g. if I'm browsing some code on Github). Either way, more ambiguity for no gains is typically not a good idea, even if the downsides are minor (again, I am very much in favor of UFCS where it's directly useful, such as C++ or D).
I have long wondered why Ruby's symbols aren't in every language.
Earlier quoted context omitted.
If you have two functions abracadabra(foo) and foo.abracadabra() which do different things , you should rename one of those functions tbh.
The problem is when you have the functions: Square.computeArea() Circle.computeArea() Clearly these should do different things. I suppose "computeArea(shape)" does dynamic dispatch based on the type of shape? But you're still putting every function defined on every type in your entire codebase in a global namespace. It's not obviously awful but I'd definitely be a bit nervous about it.
Earlier quoted context omitted.
If you can't correctly implement a circular buffer with mod (or 'and') then the language can't save you, nothing can.
"If you can't correctly implement a for loop using assembly, then the language can't save you, nothing can"
Earlier quoted context omitted.
What do you mean by “twice as many places”? And looking up definitions is a job for the language server.
Without UFCS, if I see obj.foo(), I know I can lookup the definition of foo() in the definition of obj's type, or in its supertypes. Even for foo(obj), there is often a canonical place where such functions are defined. With UFCS, I need to look in both of these places until I can find the right definition. And sure, the IDE/language server/other tooling can often help, but not always (e.g. if I'm browsing some code o…
Does anyone else disagree with kebab case over snake case?
i_used_to_think_snake_case_is_the_way_to_go_up_until_i_wrote_this_comment_out to-prove-that-snake-case-is-more-readable-but-now-that-ive-written-it-i-might-be-changing-camps