On Tuesday, 27 March 2018 at 21:02:11 UTC, 12345swordy wrote:
On Tuesday, 27 March 2018 at 20:49:25 UTC, ag0aep6g wrote:
On 03/27/2018 10:39 PM, 12345swordy wrote:
class A
{
@recursive @safe void talk()
[...]
}
class B : A
{
override void talk() // @safe attribute added by
On 03/28/2018 01:34 AM, arturg wrote:
you can call them with __traits(getOverloads, T, "name")[index];
you can overload on types attributes and linkage, but seems like you can
only merge overloads based on types.
I don't think there's value in allowing overloads that can only be
called via
On Tuesday, March 27, 2018 21:10:25 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 March 2018 at 21:05:32 UTC, ag0aep6g wrote:
> > On 03/27/2018 11:02 PM, 12345swordy wrote:
> >> Then explain this then.
> >> https://run.dlang.io/is/S2KLs5
> >
> > B.talk is @safe. The compiler ignores the
On Tuesday, 27 March 2018 at 23:34:20 UTC, arturg wrote:
On Tuesday, 27 March 2018 at 23:23:38 UTC, ag0aep6g wrote:
DMD might accept that, but I don't think it works in a
meaningful way. How do you call the @system one?
Looks like the @safe one will always be called, even from
@system
On Tuesday, 27 March 2018 at 23:23:38 UTC, ag0aep6g wrote:
DMD might accept that, but I don't think it works in a
meaningful way. How do you call the @system one?
Looks like the @safe one will always be called, even from
@system code:
import std.stdio;
void talk() @system {
On 03/28/2018 12:19 AM, arturg wrote:
shouldn't it create a overload?
I don't think so. As far as I know, you can't overload on attributes.
[...]
but this works:
class A
{
void talk() {}
}
class B : A
{
alias talk = A.talk;
void talk(int) {}
}
Because different parameters
On Tuesday, 27 March 2018 at 21:25:33 UTC, ag0aep6g wrote:
On 03/27/2018 11:10 PM, 12345swordy wrote:
Shouldn't it give a warning then?
I wouldn't mind a warning, or even an error. Putting both @safe
and @system directly on a function is an error, too.
shouldn't it create a overload?
for
On 03/27/2018 11:10 PM, 12345swordy wrote:
Shouldn't it give a warning then?
I wouldn't mind a warning, or even an error. Putting both @safe and
@system directly on a function is an error, too.
On Tuesday, 27 March 2018 at 21:05:32 UTC, ag0aep6g wrote:
On 03/27/2018 11:02 PM, 12345swordy wrote:
Then explain this then.
https://run.dlang.io/is/S2KLs5
B.talk is @safe. The compiler ignores the @system attribute on
B.talk, because A.talk's @safe attribute takes precedence.
Shouldn't
On 03/27/2018 11:02 PM, 12345swordy wrote:
Then explain this then.
https://run.dlang.io/is/S2KLs5
B.talk is @safe. The compiler ignores the @system attribute on B.talk,
because A.talk's @safe attribute takes precedence.
On Tuesday, 27 March 2018 at 20:49:25 UTC, ag0aep6g wrote:
On 03/27/2018 10:39 PM, 12345swordy wrote:
class A
{
@recursive @safe void talk()
[...]
}
class B : A
{
override void talk() // @safe attribute added by
recursive attribute and can not be removed
[...]
}
It already
On 03/27/2018 10:39 PM, 12345swordy wrote:
class A
{
@recursive @safe void talk()
[...]
}
class B : A
{
override void talk() // @safe attribute added by recursive
attribute and can not be removed
[...]
}
It already works like that. B.talk is @safe, and you can't make it
For example
class A
{
@recursive @safe void talk()
{
writeln("Hi");
}
}
class B : A
{
override void talk() // @safe attribute added by recursive
attribute and can not be removed
{
writeln("Bye");
}
}
I have notice that potential bugs can slip by the
13 matches
Mail list logo
