Overloads not returning appropriate info. [Field reflunkory]

[Alex]

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/nvpsrxxkfmbbxognjsit@forum.dlang.org
>
> https://forum.dlang.org/post/fahrmmocegtthztzgkaa@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).