51–60 of 96 posts
The author called into library which may or may not use type-level programming.
Pin doesn't have set_high()? I don't see any type-level stuff here.
If it had been:
Pin
As I don't know Rust, honest question here, just to help me understand.. The `pins.d13.into_input();` part just returns an object/reference/... of a type that only has input-specific methods, while using `.into_output()` would do the same with only output-specific methods, correct? That's nice, but why couldn't you do the same thing in C++? With a dependent type you could do `pins.d13.into(INPUT)` and get the input-s…
In C++, there's no possibility of guaranteeing that a consumed value is not re-used in the same ergonomic way using the type system. I'd imagine you can still implement something like this in C++ with some kind of move semantics and asserts, but it will be a run time error and not a statically checked error.
Earlier quoted context omitted.
> As long as your final handle has the correct type Come on. Ensuring that is the whole game!
Yeah, and it's trivial in C++, what's your point? The example looks like it's been custom tailored to show how awesome Rust is, but then the post fails to even make the point (however contrived). Why the hell would you want to change the direction of a pin anyway? Just declare it as Pin or Pin .
The author didn't show any type-level programming here. The author called into library which may or may not use type-level programming. Pin doesn't have set_high() ? I don't see any type-level stuff here. If it had been: Pin on the other hand...
Earlier quoted context omitted.
Yeah, and it's trivial in C++, what's your point? The example looks like it's been custom tailored to show how awesome Rust is, but then the post fails to even make the point (however contrived). Why the hell would you want to change the direction of a pin anyway? Just declare it as Pin or Pin .
There's no way in C++ to _statically_ guarantee that you don't simultaneously have the floating pin handle and the output pin handle. You cannot do it.
I mean, I could easily come up with a contrived example that Rust can't do as well, but what's the point?
Earlier quoted context omitted.
It could, but the comparison to Arduino still makes more sense since that's very well known and is pretty much C. It makes very little use of C++ features. Especially advanced stuff like this - probably partly to avoid difficult error messages for beginners and partly because the Arduino developers (the original ones at least) were shit at API design.
Yeah, but then the example is anyway flawed, type level programming is also a thing in C++.
Earlier quoted context omitted.
There's no way in C++ to _statically_ guarantee that you don't simultaneously have the floating pin handle and the output pin handle. You cannot do it.
I agree, I'm just waiting for someone to explain why I should care; what's the reason to not declare the pin statically as either or? I mean, I could easily come up with a contrived example that Rust can't do as well, but what's the point?
That for plenty uses cases, pins are not statically either or, but are switched at runtime. (and the article really fails IMHO by not showing that, because doing that while keeping compile-time checks is the hard part, and its limits would be really interesting)
Earlier quoted context omitted.
Yeah, but then the example is anyway flawed, type level programming is also a thing in C++.
Sorry would that be any C++, modern C++ (as described 10 years ago), modern C++ (as described 5 years ago), modern C++ (as described today), a special C++ subset known to MCU folks or something else?
Type level programming is possible in C++98.
Easy to reach for in most embedded compilers, when people actually use C++ compilers for C++, and not the C subset.
Earlier quoted context omitted.
It’s not a contrived example. It’s the canonical embedded hello world, written against two different libraries. At any rate, the C++/Rust part can be a distraction, because the interesting point here is the technique of encoding program state in the type system.
>"At any rate, the C++/Rust part can be a distraction" that was exactly my point. >"interesting point here is the technique of encoding program state in the type system." It is "interesting" but there is nothing new about it.
Earlier quoted context omitted.
Yeah, and it's trivial in C++, what's your point? The example looks like it's been custom tailored to show how awesome Rust is, but then the post fails to even make the point (however contrived). Why the hell would you want to change the direction of a pin anyway? Just declare it as Pin or Pin .
There's no way in C++ to _statically_ guarantee that you don't simultaneously have the floating pin handle and the output pin handle. You cannot do it.
It the implementation code pretty?
Most likely not, but here we are discussing what is possible, not beauty.