Alex-Kent

Whatever is implemented a POSIX-compatible `printf(format_string, arguments)` should be one of the options. This could be alongside of (or in place of) `format(format_string, arguments)` but regardless I think `printf` should...

In the original post one of the issue links is wrong; this: > https://github.com/openscad/openscad/pull/5887 (number formatting) should be: > https://github.com/openscad/openscad/pull/5587 (number formatting)

> [`printf`'s syntax is] not even matching in any useful form to OpenSCAD with it's non-machine-language data types What's an example of something that would be awkward to express using...

> It isn't quite clear how undef and boolean map to printf format specifiers I'd go with something like: * `sprintf("%i", undef)` → `0` * `sprintf("%f", undef)` → `NAN` *...

Elaborating further, one might allow user-defined formatting. For example: ```c $printf_formatter = function(value, format) format=="b" // For boolean ? is_undef(value) ? "-" : value ? "T" : "F" : undef;...

Attached is an overview of the arguments accepted by the `printf` functions in various popular languages¹. A few features from Ruby's implementation in particular might be adapted: * `%{name}` →...

> Yes, that's a key problem with printf. Python's format(), on the other hand, can use named tags: One could implement Ruby's syntax for this: `%format` For OpenSCAD this could...

> +1 for Python style. … KISS, v strings of meaningless special characters. In all but the trivial case¹ Python's `format` is a **lot** more complex than `printf`, even if...

> named tags solves the prob with order of format codes not matching the order of the arguments Agreed, that would be a nice feature to support. It's not `format`-specific...

> popularity I see no reason not to adopt a sensible solution from a less popular language solely because the language isn't popular.