On Friday, 9 February 2018 at 15:25:51 UTC, jmh530 wrote:
On Friday, 9 February 2018 at 13:47:51 UTC, Atila Neves wrote:
On Friday, 9 February 2018 at 08:27:21 UTC, Nick Sabalausky

And yes, things like "inout", "auto ref" or whatever, and such, strike me as indicative of more fundamental design flaws. (Not "flaw" in the sence of "mistakes" necessarily, but "flaw" in the sence of "there must be a better way to design these things...")


Yeah, something like traits in Rust or typeclasses in Haskell would be a lot better. Fortunately, one can kinda-sorta get there with a library solution. Check out `@implements` in https://github.com/atilaneves/concepts

I'm confused. While I get how @implements resolves the same issues as Rusts's traits, I don't see how traits resolve the same issues as inout/auto ref. My understanding is that inout and auto ref mean you don't have to write multiple versions of the relevant functions. Moreover, while one could use templates to do something similar, inout/auto ref are designed to reduce code bloat. I don't think Rust's traits can accomplish the same thing, but I'm not familiar enough with Haskell's typeclasses to know.

I must have quoted the wrong thing. I posted @implements in response to CT vs RT when it comes to interfaces. Think isInputRange vs an interface. Rust's traits allow one to use what looks like an interface in D (or Java, etc.) for compile-time contraints that also works at runtime. I wish we had that.

I wasn't saying anything about inout/auto ref although I like both of those.


Reply via email to