3 ms·
That “.” substitution of an inferred type is going to fire back. I really appreciate when code has one simple property: you search a type by name and you get al
by kvark 2y ago
That “.” substitution of an inferred type is going to fire back. I really appreciate when code has one simple property: you search a type by name and you get all of the places where it’s constructed. Makes it easy to refactor the code and reason about it with local context. It’s the case with Rust, but not C++ or Zig.
- zamadatix 2y agoWhat's meaningfully different in Rust's type inference. E.g.: fn example() { let p = returns_a_point_type(args); } Where create_point() is a function from a module (e.g. not even defined in that file) which returns the Point type automatically inferred for p? I mean sure, it's technically constructed in the called function... but is that often a useful distinction in context of trying to find all of the places new instances of types are being assigned? In any case, this is something the IDE should be more than capable of making easier for you than manually finding them anyways.
- nindalf 2y agoGP is talking about how easy it is to find places where the type is instantiated. Seems to me that create_point() will have one such site. And then it’s trivial to find callsites of create_point() with the LSP/IDE. What’s the issue?
- zamadatix 2y agoThe IDE can find all places new variables are assigned to the type (regardless of whether it's direct instantiation, return value, inferred, or whatever way it comes about) so what's the special value of being able to manually find only the local instantiations find ctrl+f if you'd still need to manually track down the rest of the paths anyways?
- int_19h 2y agoAny IDE worth its salt will let you search a type by name and get all the places where it's referenced, regardless of type inference.
- alpaca128 2y agoA language that promotes itself as simple and with no hidden control flow etc shouldn't need an IDE to find hidden things imho. But that kind of shortcut seems to be optional.
- int_19h 2y ago"No hidden control flow" is completely orthogonal to "no implicit typing". I think anyone looking at Zig would immediately recognize that it is firmly in the type inference camp by choice. As far as simplicity, I think their pitch is "simpler than Rust", not in absolute terms. The whole comptime thing is hardly simple in general.
- alpaca128 2y agoTheir pitch is "A Simple Language" as seen on the website.
- ablob 2y agoI think it is simple, but not easy to grasp. I might be quibbling over words, but these things are not quite the same in my eyes. simple <-> complex easy <-> difficult
- chamomeal 2y agoI know this gets shared all the time, but in case anybody in this thread hasn’t seen the rich hickey talk: https://youtu.be/SxdOUGdseq4?si=3sa6JRg6Ei1Cf_Wl https://youtu.be/SxdOUGdseq4?si=3sa6JRg6Ei1Cf_Wl
- binary132 2y agoI am not a big Zig aficionado but I definitely contrast it in my mind moreso with C and C++ rather than Rust. It definitely aims at being a “better C” sort of language moreso than a “better C++” which Rust seems to be focusing on.
- fuzztester 2y ago
- flohofwoe 2y agoThis is tedious in Rust when initializing a struct which has nested structs. A language which has type inference at all should at least be consistent about it and allow to not mention the type when it can be inferred by the compiler.
- rererereferred 2y agoAn easy way to find all places is to temporarily add a new struct member without defaults, run the compiler and let it complain of all the places where it is being instanced. Similar to when you add a new enum member and it complains of all switch statements that are not using it (as long as you didn't add a default case).