Added different message to distinguish between two cases:

[zerkms]

a) the value at the path is of the wrong type
b) the path does not exist

Fixes #494

IMPORTANT: this is still "work-in-progress" and merely a conversation opener with the aim to find out better wording (not sure I like it like that, but it's the best I could think of at the moment).

[coveralls]

Pull Request Test Coverage Report for Build 11711748423

Details

• 47 of 47 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.005%) to 98.696%

---

Totals
Change from base Build 11369981368:	0.005%
Covered Lines:	5375
Relevant Lines:	5446

---

💛 - Coveralls

[veewee]

Wouldn't this be "null" on nested shapes where one of the underlying keys does not exist? (given that you pass null as a string to the parent exception?

(same comment for CoercionException)

[zerkms]

I don't understand what it means, could you expand? If the "outer" shape does not match - no "nested" shapes will be checked, right?

[veewee]

For example:

shape([
    'a' => shape([
        'b' => mixed()
    ]),
])->coerce(['a' => []]);

This will result in:

Could not coerce "null" to type "array{'a': array{'b': mixed}}" at path "a.b"
 -> Previous:  Could not coerce to type "array{'b': mixed}" at path "b" as the value was not passed.

If the "outer" shape does not match - no "nested" shapes will be checked, right?

The types will coerce top-down indeed. But if one of the nested children results in a failure, the exception gets wrapped and enriched with the "path" information. It's that $first logic inside the exception constructor which you default to ?? 'null'.

[zerkms]

Oh yes, now I see that CoercionException and AssertException should be monadic. How about now?

Only for CoercionException yet, as a proof-of-concept.

And a mandatory reminder: this is still under heavy WIP, I understand it's not a trivial change and I will clean things up during the final git squash.

[veewee]

I don't think wrap()-ing it is the way:

vec(
    shape([
    'a' => shape(['b' => mixed()])
    ])
)->coerce([['a' => []]]);

Could not coerce "null" to type "vec<array{'a': array{'b': mixed}}>" at path "0.a.b"

The parent's exception construction should be more aware of those details from within the child's type exception.
Maybe an alternate suggestion would to make the $actual and $first property nullable for those situations where the value is not available and let that decide the message instead?