On Sunday, 7 April 2019 at 15:26:47 UTC, Adam D. Ruppe wrote:
On Sunday, 7 April 2019 at 03:47:25 UTC, Alex wrote:
What you need to tell me is why using .stringof is bad. You
have simply conjured up a rule and are stating it but not
giving any reason why it is not a good idea to follow when, in
fact, not following can be shown to be beneficial.
You can't expect to lead by authority. Give a good reason why
I should avoid it and change my current ways and I will.
I have a couple times times now.
https://forum.dlang.org/post/nvpsrxxkfmbbxognj...@forum.dlang.org
https://forum.dlang.org/post/fahrmmocegtthztzg...@forum.dlang.org
I go into a lot of detail in the link on the second link.
And the pains you are personally experiencing are a direct
result of stringof. If you were to actually following my rule,
you'd learn by doing how much better it is.
That is blatantly wrong. The code works EXACTLY the same way with
and without using stringof.
You have not stated one type the reason why T string of is bad,
you have just stated that it is bad, that is totally different.
I have removed all T.stringof's in the code and I still get the
exact same errors. Your assessment that all the errors are due to
T.stringof is wrong.
You need to provide code where using T directly works but
T.stringof fails.
I did a search and replace for all the T.stringof's and the code
produced the exact same output, so to say that is the source of
all my problems is BS, and since I have already fixed most of the
problems(the main ones of inout and protection still exist) after
that, it shows that it had nothing to do with it.
I'm not saying it is a good idea, what I'm saying is that you
haven't yet given any proof why it is a bad idea. Those links are
you just stating it is bad.
If you want this not to be a waste of both of our times, next
time post an example code that demonstrates the problem.
So it seems like the same design flaw exists? Have any work
arounds for that?
It won't work for private, you can use static if
__traits(compiles) as a filter to get rid of them.
That doesn't help. It is compile time, one should be able to get
the information. It is pointless to exclude it at CT because one
could just open the source if there was anything to "hide".
Protection is a runtime thing(except for CTFE).
