Compiler patch for runtime reflection

[Gor Gyolchanyan]

Requiring explicit request for reflection contradicts D's "safety
first, performance second" policy.
lack of reflection is a safety issue too, because you won't be able to
do some checks.

On Tue, Oct 25, 2011 at 7:31 PM, Gor Gyolchanyan
<gor.f.gyolchanyan at gmail.com> wrote:
> As i said before, enabling reflection manually is an act of enabling a
> certain range of stuff you can do with the code. Forgetting to enable
> reflection can lead to serious problems, when the reflection is
> required.
> disabling reflection manually is an act of optimization purely.
> Forgetting to disable the reflection can only lead to unnecessary data
> being stored.
>
> The second scenario is much less error-prone.
> yes, it _may_ lead to code bloat if you forget to disable it where it
> is _absolutely positively unneeded_, but forgetting to enable it will
> just make your code useless in many situations.
>
> On Tue, Oct 25, 2011 at 7:20 PM, Robert Jacques <sandford at jhu.edu> wrote:
>> On Tue, 25 Oct 2011 07:30:04 -0400, Gor Gyolchanyan
>> <gor.f.gyolchanyan at gmail.com> wrote:
>>>
>>> You can always write @noreflect: at the start of your module and it
>>> will work as expected. what's the problem with that?
>>> Also, compiler would be able to automatically add that attribute to
>>> any symbol, which is private and does not escape the module.
>>> Again, not including reflection is purely _optimization_ issue and
>>> should not be interfered with it's functionality.
>>> Reflection is something you rarely have in mind when designing, for
>>> example, classes.
>>> Requiring explicit request for reflection defeats the purpose.
>>>
>>> You could just as well say "writing public on every member is a
>>> clutter". It is, but you don't have to do it to achieve the same
>>> effect.
>>
>> You can always write @reflect: at the start of your module and will work as
>> expected. what's the problem with that?
>>
>> Rhetoric aside, Timon wasn't referring to code clutter on behalf of the
>> programmer. He was referring to code bloat in the compiled program. The two
>> are very different things.
>>
>> Also, just because reflection is something you rarely have in mind when
>> designing, doesn't mean it shouldn't be part of the design API. Reflection
>> is somewhat equivalent to the extern protection modifiers and so should
>> warren careful consideration. Furthermore, bugs with reflection, say due to
>> a change in the API, don't break during compilation; they break at runtime.
>> And practically, there's a decent change your customer, not your test suite,
>> is going to find it.
>>
>