Functions with package protection

[Jarrett Billingsley]

On Thu, Jun 4, 2009 at 7:01 AM, Denis Koroskin <2korden at gmail.com> wrote:
> On Thu, 04 Jun 2009 07:36:35 +0400, Jarrett Billingsley <jarrett.billingsley at gmail.com> wrote:
>
>> On Wed, Jun 3, 2009 at 10:02 PM, Christopher Wright <dhasenan at gmail.com>
>> wrote:
>>> Robert Fraser wrote:
>>>>
>>>> grauzone wrote:
>>>>>>
>>>>>> Sorry to dig up this old post, but I still don't understand why
>>>>>> 'package' functions cannot be virtual? Is there a good reason for
>>>>>> this? I
>>>>>> can't see why we can't use polymorphism on 'package' functions!
>>>>>>
>>>>>> Is there way to make it virtual without making it public? (e.g. a
>>>>>> 'virtual' keyword?)
>>>>>
>>>>> "package" needs to fixes:
>>>>> - package methods must be allowed to be virtual
>>>>> - package methods must be allowed to be accessed from sub packages
>>>>> (module a.b.x should be able to access package identifiers declared in
>>>>> module a.y)
>>>>>
>>>>> I don't understand why these fixes applied, especially because they
>>>>> are
>>>>> completely backward compatible.
>>>>
>>>> "package methods must be allowed to be virtual" isn't
>>>> backwards-compatible. This code will work differently if package
>>>> methods
>>>> were made virtual:
>>>
>>> That's a larger problem, I think: you can override methods silently. The
>>> override keyword should be required.
>>
>> It is in D2.
>
> Since when?

Since 2.004.  I guess it's a warning and not an error, but I always
compile with warnings anyway.  In any case, it's almost *always* an
error.