-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remove ties to stringification of io.write #13277
Conversation
maybe we need to replace existing # overloads like these
proc appendStr*(result: var string, a: int) = ...
proc appendStr*[T](result: var string, a: T) = ...
proc `$`*[T](a: T): string = appendStr(result, a) (see also https://dlang.org/changelog/2.079.0.html#toString) |
@timotheecour Yea, that would fix the problem. For quite a while I was hoping that |
bab5e30 was a good change;
|
@timotheecour I never had problems in my generic code trough |
see #13345 for a cleaner fix IMO, which fixes the root cause of #13182 ; the other points (regarding temporaries and ties to stringification) remain valid, but hopefully there's a cleaner way to tackle that rather than introducing all those overloads (which cause generic bloat, for each unique instantiation of params, unlike |
@timotheecour First of all, yes you fixed a bug, and that is generally a better solution than breaking changes. However, I disagree that you fixed the root cause instead of a symptom. The root cause is the varargs overload that uses generic |
import system except write
system.write(stdout, 1234) # now needs FQ
stdout.write 0.1, " to_stdout ", 12, "\n" # prints 0.1 to_stdout 12 to have it available without dependency on macros.nim is also possible modulo a simple compiler patch (IIRC), as noted in RFC. |
@timotheecour, sometimes I really don't get you. How does |
import system except write
template write(f, a) = system.write(f, a) then the example in #13182 works, effectively masking |
@timotheecour ok I think I get the idea. But I would require typed templates and add templates for all types that I want to have. Not nice code, but it could work. Thank you. |
67e9eed
to
70dab90
Compare
442112f
to
5408ae0
Compare
Where is the RFC that covers this change? Where is the vote on the RFC? Where is the migration period? |
@Araq Well this is the RFC, but as a PR. I did it this way because of CI. The official RFCs repository does not have CI. The question though is, what should I do? Should I open an issue on the RFCs as well, to be formally correct? Should I elaborate there more about the type of problem that I am trying to fix? Or should I elaborate here more on it? If I should elaborate more, on what should I elaborate? What is the part that you don't understand? Regarding the votes. Since when do we have a democracy in Nim? |
Well exactly, so you start by writing an RFC that explains the benefits of your changed IO procs and then see if it can get a consensus. And then once accepted you can implement it, or you refer to an "already existing implementation" in this very PR, pointing out that all the tests are green, so that we know the code breakage at least doesn't affect the "important packages".
We don't, yet we value the feedback from the community and I don't use my dictatorship status all the time. |
Well then I will an RFC pointing to the PR. For this change it was important to know ahead of time that no important packages would be broken by this change. |
This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions. |
Normally I would do such an implementation with macros, but they are not available in system.nim.
This is a breaking change. uses of
write
that rely on stringification won't work anymore. They will get an easy to fix compilation error though.This PR is still raw.
harmfulOverloadOfWrite
isn't a good name, there is no test added,writeLn
also needs to be adapted. I am just curious if a change like this could be welcome, or if I have to fight windmills again.Personally a change like this would be really valuable to me. As you probably know I really don't link the
$
stringification with its intermediate objects, and I don't likevarargs
.echo
has both of it. I tried to get rid of the$
fallback in string interpolation, but I got massive negative feedback and it is back in there.write
that works onFile
also has the$
fallback. There is simply nothing currently in Nim that doesn't secretly inject the$
function for printing inNim
. String interpolation andecho
seems to popular to break, so I won't touch them, Butwrite
andwriteLn
could be non-popular enough to be used as a$
free printing environment.would fix #13182
Very much like nim-lang/RFCs#191 this solution is extendable, but the extendable proc isn't a binary
$
or anappendStr
proc, it is justwrite
, which we already have. But unlike that RFCwrite
doesn't need a single intermediate string allocation, where the RFC does create one intermediate string object per call toecho
or variadicwrite
.A generic
$
could be implemented using an in memory file object, e.g. withFILE * open_memstream (char **ptr, size_t *sizeloc)
. But that is not very portable for all the backends.