Golang big.Float is not a big decimal about cucumber-expressions

[mpkorstanje]

The mapping of bigdecimal to big.Float should be removed in the golang package and consumers should be allowed to register a correct decimal implementation (none is provided by the standard library).

That is perfectly acceptable. I'm kinda surprised that the big-decimal test case passed. I suppose we haven't quite added enough digits to it.

Would you be able to send pull request for this? Feel free to update the big decimal test case with enough digits to make it fail and then exclude the big decimal test case for Go. If other languages start failing we can look at those separately.

edit: I'm going to find a bigger consensus on this. I'd like to revert most if not all of #42.

Also in the golang implementation, it seems like it's an error to override a built-in type mapping. It might be worth reconsidering this in case users want to swap out other type mappings.

That sounds reasonable but I'd like to find a larger consensus.

[mpkorstanje]

Note: I find the rationale from #42 to add {bigdecimal} to every language rather shaky. There don't appear to have been any other alternatives considered.

[mpkorstanje]

The test case for big decimal also appears to be intentionally hamstrung to avoid the problems caused by a lack of precision. Compared to the big integer test case we're missing quite a few digits.

[aaronc]

In the meantime should I submit a PR to disable the golang registration of bigdecimal?