What type of `print` formatting do you prefer? (page 2)

On Tuesday, 21 December 2021 at 22:20:52 UTC, russhy wrote:

no need for the index imo, just {}, and inside you can but specifics like mentioned above

Like I said. While rare, there will be cases while this will be useful so I will support it. BUT it will not be necessary to use and it should not be used for most cases. You and I will use the simple "{}" syntax ;)

that's cleaner, easier to read, and easier to write and manage

Exactly! That's my point and like I said, it will be easier to implement manual format with the brackets. I'm still working on the design of manual formatting tho.

if someone passes a struct, then you could check if it has a function with __traits print(void* filep) and call it for custom prints

Yep, supporting methods for Structs was planned anyway! In case the type is not the basic type then the compiler will check if the type has a method (I will think about the name) and if it has it, it will call this method, if not, it will inform the user and abort compilation

this is how string interpolation should be done in D
no need complex things, i like OP's idea, i'd use it (if it remains nogc :p)

Yes, there will not be a garbage collector now or never!! Libd (lib's name) will be a low-level (using inline assembly) system library using the -betterC and --Xcc=-nostdlib flags to compile. This will allow us for great runtime performance and fast compilation times and of course no dependencies!

December 22, 2021

Re: What type of `print` formatting do you prefer?

Posted by rempas
in reply to Paul Backus

Permalink

rempas

Posted in reply to Paul Backus

Permalink

On Wednesday, 22 December 2021 at 01:40:02 UTC, Paul Backus wrote:

One of the big advantages of C's format-string syntax is that its conventions are largely shared across programming languages. For example, if you know what %d means in C, then you also know what it means in Java, Go, D, and any other language that uses C-style format strings.

I understand what you are saying but my problem with this thought is that we should not consider something like that because what I'm always saying is that we should evolve and learn new things rather that sticking to the old things. Of course if the old things are better, we should stick on them and if we are going to evolve on something, we must make it better on EVERYTHING (well it's not possible to make something better in 100% of the areas but you get my point). So I don't like the idea of using the old way of doing it because people know about it. If we make something better (and I think the "{}" syntax is better as I explained why) then I think people will stick and learn it (and love it :P). For that reason, I think we should invest on something new that may be the standard one day. Don't forget that the curly bracket syntax is not new anyway, a lot of languages already support it. With this conclusion,

If you are planning on designing a new {}-style format-string syntax, I would strongly recommend aiming for consistency with other languages like Python, Rust, and C# that use {} for string formatting. For example: all of those languages use {0} to insert the first parameter, {1} to insert the second, and so forth, so your new library should do the same.

Like I said in previous replays, this will be useful in some cases so I will implement it but only as optional. This way a lot of people that don't want to use it (including myself) will not have to use it and people that want to use it will be able to use it. This is the best way having both sides happy (which is something I really do care) and it's one of the very few things that we can keep 100% of the users happy so I'm very confident with this approach.

Forums