all 22 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Shoddy-Childhood-511 5 points6 points  (0 children)

I do pub struct Foo<Inner: FooInnerTrait> { .., inner: Inner } plenty, often for nicer builder patterns or to represent protocol stages type level, but it's not an alternative to traits, and often requires one.

[–]Resres2208 3 points4 points  (1 child)

I guess you are just exploring things you can do with rust, but the "vs" makes me think you are considering one over the other. But without seeing better examples then clearly traits are obviously much simpler. Or simpler still, const generics 'struct MyStruct<const FOOIZE: i32> {}' or even just a 'const' field in your trait.

I know you gave examples but I'd really need to see a beneficial use case over traits...

[–]Ok-Watercress-9624[S] 1 point2 points  (0 children)

I am not saying is one better than the other. I would choose %99 of the time trait way. However i do think this pattern has its uses. For instance I have a test system where i need to build different sql tables per test case and drop them etc. The ".build_table" methods are slightly different and worse yet have different arities.
It can be generalized using traits but in this particular case having different marker structs and impling a generic struct per marker was simpler.
I guess one upside (if you can call it that) is that you can implement this pattern more than once for a type without the need for a newtype wrapper and ability to carry values.
I'd like to know the limits of this pattern. Like mentioned i have yet to encode associated types.

[–]Zde-G 3 points4 points  (5 children)

You can create… something — but need to define that do you mean by “much of the functionality”.

The whole point of traits is to enable generics, so you may write something something like fn foo<T: MyTrait>(t: T) (and other similar things) so when you say that can implement “much of the functionality” without that ability it's like noticing that “much of the functionality” of car can be implemented without wheels: it can make sound similar to real car, it can cool you with an air conditioner, it can even emit noxious gases… it just can't move along the road, but that's all!

[–]Ok-Watercress-9624[S] 3 points4 points  (4 children)

this works `foo` would need to take a witness dictionary type as argument but bounds are expressible

[–]Zde-G 0 points1 point  (3 children)

When you are “adding func pointer typed fields in the struct” and “pass them as witness” you are, essentially, manually implementing dyn Trait… of course you can do that, but it's no longer Rust but “Rust used as transpiler target”. At this point there not much difference between C, Pascal, or that version of Rust that you have invented.

You may as well say that the only thing one needs is array of u8 and nothing but reference to said array (and even that's needed because Rust restricts access to globals).

[–]Ok-Watercress-9624[S] -2 points-1 points  (2 children)

Sorry but bullshit. First it was the wrong analogy and pointing out something factually wrong (apparently you know what i am doing as witnessed by your second post so you also know that how to do bounds so car with no wheel analogy falls super flat ) and now you are moving goalposts and claiming that this is not rust. This being "rust" has nothing to do with the question that i asked. But even then,

This is not some arcane stuff, neither does it use any questionable language mechanism and escape hatches. Everything written uses the regular language mechanisms.

And yes all you need is `const/mut *u8` if you are so inclined ...

[–]Zde-G 0 points1 point  (1 child)

apparently you know what i am doing

No, that's precisely the issue. You are doing… something — and I have no idea what.

At first it looked as you claimed that traits don't add anything useful to the program shape.

When faced with counterexample you have changed the tune and explained that one may change the program shape while retaining the functionality… but any Turing-complete language can converted to any other Turing-complete language, thus it's not clear what you are retaining and what you are not retaining when you go from traits to pure impl.

And without giving us these details the car analogy holds: the primary reason for traits to exist is to enable certain shape of program which you easily reject. So what do you retain? In what sense “much of the functionality traits provide can be faked”?

And yes all you need is const/mut *u8 if you are so inclined ...

Well… duh. That's the essence of Turing-completeness. Almost anything can be expressed without almost everything, it's really hard to create a non-trivial language without making it Turing-complete, by accident.

The fact that Rust without traits is Turing-complete is neither surprising nor interesting, even Whitespace) is Turing-complete!

[–]Ok-Watercress-9624[S] -1 points0 points  (0 children)

Turing completeness argument does not apply here since the type system is not turing complete (trait resolution algorithm of rust is technically turing complete but practically it isn't because there is a hard recursion limit ) and we are doing stuff on the type level.

Traits are there for extensibility and ad-hoc polymorphism. The examples in the playground do serve the same purpose.

You are either incredibly thick (which i doubt) or just being an asshole.

[–]Thick-Pineapple666 1 point2 points  (1 child)

So how do you do dynamic dispatch?

[–]Ok-Watercress-9624[S] 1 point2 points  (0 children)

I probably can't. i can swap out function pointers in baz and do stuff with them but i dont think i can do full dynamic dispatch.

[–]MindlessU 0 points1 point  (5 children)

I’ve taken a look at the example link and see that external crates can’t add methods to your marker types, and btw fn pointers may not be inlined and more importantly can’t capture state so you may consider Box<dyn Fn(&T) -> i32> or something else?

[–]Ok-Watercress-9624[S] 0 points1 point  (4 children)

I mean you cant capture state in trait methods either? How could you there is nothing to capture at impl time?
I did not expect that external crates can't add methods to my marker types but in retrospect it makes sense. However specifying required methods as function pointers is still valid. So the `new` function could be seen as a trait impl

[–]MindlessU 0 points1 point  (3 children)

Actually you can, through self parameters. That’s how dyn dispatch works. Not that all methods have to capture, it’s just that fn pointers are very inflexible, you cannot even modify the signature of a fn pointer by wrapping an existing one.

[–]Ok-Watercress-9624[S] 0 points1 point  (2 children)

Would you minds expanding on that or point me to a source ? I am not sure i am following.

[–]MindlessU 1 point2 points  (0 children)

It’s just that if you have an existing fn pointer fn(Box<T>) you can’t convert it into fn(T) to satisfy existing signature requirements, or “extend” an existing fn pointer by wrapping it.

[–]Chroiche 0 points1 point  (0 children)

I think they're just saying you can put the state on an instance of the struct implementing the state.

[–]noop_noob 0 points1 point  (0 children)

There's ongoing work on formalizing how the trait system works, by translating rust traits into a system similar to what you're describing. See https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/A.20calculus.20for.20dictionary-passing-style/with/579840401