On Monday, 11 September 2017 at 20:40:30 UTC, nkm1 wrote:
I don't know, maybe don't use alias this :) IMO, it's a really
dubious feature...
I don't think it's an issue of alias this, per se. I think it's
just something to be aware of and use your approach of aliasing
as necessary. It's
On Monday, 11 September 2017 at 18:15:36 UTC, jmh530 wrote:
An interesting example. I'm not sure overriding is the issue so
most as what is in the overload set. I think foo(int) is not
part of the overload set yet. The compiler is able to cast the
long to int and then call the one in class B
On Monday, 11 September 2017 at 17:59:25 UTC, nkm1 wrote:
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
I suppose my issue is that final should prevent function
hijacking because I shouldn't be allowed to override string
bar(double d) anyway. It shouldn't be a worry.
It has
On Monday, 11 September 2017 at 15:13:25 UTC, jmh530 wrote:
I suppose my issue is that final should prevent function
hijacking because I shouldn't be allowed to override string
bar(double d) anyway. It shouldn't be a worry.
It has nothing to do with overriding. Consider:
import std.stdio;
On Monday, 11 September 2017 at 04:29:39 UTC, Ali Çehreli wrote:
Here, the feature called "name hiding" is in effect. Foo2.bar
hides all bars from Foo. This is to avoid "function
hijacking"[1].
Ali
[1] https://dlang.org/hijack.html
I suppose my issue is that final should prevent function
On 09/10/2017 08:14 PM, jmh530 wrote:
> In the code below, the second to the last line fails to compile. As far
> as I can tell it is because the override also overrides all overloads. I
> could imagine why it would occur with a virtual member function, but I
> would think it wouldn't be
In the code below, the second to the last line fails to compile.
As far as I can tell it is because the override also overrides
all overloads. I could imagine why it would occur with a virtual
member function, but I would think it wouldn't be necessary with
a final one.
@system
unittest
{
