C++ doesn't have type inference at all which I understand requires constraint solving.

It has a much simpler type deduction system where the type of an object is deduced from its initializing expression, i.e. deduction always flows in one direction.

It is nowhere as powerful, but it does cover a lot of use cases.

One advantage (in addition to the ease of implementation) is that, except for circular definitions, there are no undecidable cases and it is not necessary to restrict the type system to prevent them.

not that im advocating it per se, but couldnt you deduct the tyope based on what `zagizuga()` does with `sepulka`?

for example

  def sepulka(zagizuga)
    zagizuga.doSomething()
    zagizuga.doSomethingElse()

would infer the type of zagizuga as some object that implements two methods `doSomething()` and `doSomethingElse()`... i think that should be doable (and possibly extremely slow) right?

maybe i missed something...

Yes, it is doable, but what if there several memory-layout incompatible classes which implement both methods?

E.g, A implements virtual doSomething() and B and C inherit from A, add some different fields and both implement doSomethingElse() which they should overload for their inheritance from class Z.

good question, i guess it depends on the language... multiple inheritance without namespacing would either result in either method getting chosen randomly, or a build error...

for example, in swift you cant even inherit from two protocols that have default implementations... and i think in c++ you also cant call the method without specifying namespace...

so, i suppose, if you wanted to go all the way, you could even do namespace inference

  def sepulka(zagizuga)
    zagizuga::Something.doSomething()
    zagisuga.doSomethingElse()

so zagizuga is infered to be some type that inherits from `Something` namespace and expects that namespace to defined `doSomething()` function, in addition to providing `doSomethingElse()`

though that seems getting a bit fragile irl maybe...