Quoting massimiliano.marcon from slack:

We are trying to finalize the user-facing representation of BSON types in the shell. We would like to have something that is readable, not overly verbose and that can be copy pasted back into the shell. At the same time, we want to be as consistent as possible to the driver’s semantic.

Initially, we had gone with e.g. Decimal128('12.3') but that does not satisfy the criteria of being able to copy-paste back into the shell. If I do that, I get no errors but I do get an unexpected result as the Decimal128 takes a buffer and not a string and does not do any type checking.

I was wondering if it would be reasonable to have the constructors for BSON types accept a string in addition to whatever they accept now. I know that probably since the beginning it’s always been like that and that there is a fromString method to create a BSON object from a string but I lack the historical/technical reasons for that. Even from the perspective of the user of the driver, I think I’d probably start from a string most of the times I need to create a BSON object.

I don’t like the idea of showing the results of a query with Decimal128.fromString("12.3") , that’s overly verbose and not really what I’d expect. We could obviously handle it on the mongosh side and have a Decimal128 constructor that takes a string, but then that would create a discrepancy between the shell and the driver that might lead to confusion if someone tries to reuse their code passing it to the driver.

All the examples here are with Decimal128 but obviously the same applies to the other BSON types. (edited)

In concrete terms, we would like the Decimal128 constructor and Long constructor to accept strings as input. Currently, there is no strong typechecking in place, but passing a string to these methods is not something that yields meaningful results, so I don’t think there are backwards compatibility concerns here.

If this does pose a backwards compatibility challenge, exploring other options would be nice, e.g. template string literals (like Decimal128 `123`), or e.g. Long could also just accept a single bigint argument.

Because this would affect how e.g. mongosh output in documentation and educational material looks like, it would be good to see this change soon. I am happy to provide an implementation, assuming that one is being agreed on here.