On Wednesday, 26 May 2021 at 18:58:47 UTC, JN wrote:
On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
You can drop this straight into run.dlang.io:
import std.stdio;
class base{ float x=1;}
class child : base {float x=2;} //shadows base variable!
void main()
{
base
On Wednesday, 26 May 2021 at 18:58:47 UTC, JN wrote:
I am not buying the "C++ does it and it's legal there" argument.
A point for it is the consistency with methods which also
redefine super methods as default strategy.
The question is if the default strategy needs to be changed?
I wouldn't
On Wednesday, 26 May 2021 at 18:58:47 UTC, JN wrote:
Is there any viable usecase for this behavior? I am not buying
the "C++ does it and it's legal there" argument. There's a
reason most serious C++ projects use static analysis tools
anyway. D should be better and protect against dangerous
On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
You can drop this straight into run.dlang.io:
import std.stdio;
class base{ float x=1;}
class child : base {float x=2;} //shadows base variable!
void main()
{
base []array;
child c = new child;
array ~= c;
On Wednesday, 1 July 2020 at 20:05:51 UTC, tsbockman wrote:
If you want the compiler to stop you from accidentally keeping
references to stack variables past the end of their scope, you
need to annotate your functions @safe and compile with
-preview=dip1000: https://run.dlang.io/is/3VdDaN
On Tuesday, 30 June 2020 at 16:36:45 UTC, H. S. Teoh wrote:
And on that note, this implicit static -> dynamic array
conversion is seriously a nasty misfeature that ought to be
killed with fire. It leads to bugs like this:
struct Database {
int[] data;
On Wednesday, 1 July 2020 at 15:57:24 UTC, Nathan S. wrote:
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code
On 7/1/20 11:57 AM, Nathan S. wrote:
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
permitted, because it's
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Why does such code compile? I don't think this should be
permitted, because it's easy to make a mistake (when you wanted
foo[index] but forgot the []). If someone wants to assign a
value to every element they could do foo[] = 5; instead which
On Tuesday, 30 June 2020 at 16:22:57 UTC, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
permitted, because it's
On 6/30/20 2:22 PM, H. S. Teoh wrote:
On Tue, Jun 30, 2020 at 02:06:13PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
[...]
I take it back, I didn't realize this wasn't something that happened
with dynamic arrays:
int[] dyn =
On Tue, Jun 30, 2020 at 02:06:13PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
[...]
> I take it back, I didn't realize this wasn't something that happened
> with dynamic arrays:
>
> int[] dyn = [1, 2, 3];
>
> dyn = 5; // error
>
On 6/30/20 12:37 PM, Steven Schveighoffer wrote:
On 6/30/20 12:22 PM, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
On Tue, Jun 30, 2020 at 04:50:07PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Tuesday, 30 June 2020 at 16:41:50 UTC, JN wrote:
> > I like my code to be explicit, even at a cost of some extra typing,
> > rather than get bitten by some unexpected implicit behavior.
>
> I agree, I
On Tuesday, 30 June 2020 at 16:41:50 UTC, JN wrote:
I like my code to be explicit, even at a cost of some extra
typing, rather than get bitten by some unexpected implicit
behavior.
I agree, I think ALL implicit slicing of static arrays are
problematic and should be removed. If you want to
On Tuesday, 30 June 2020 at 16:37:12 UTC, Steven Schveighoffer
wrote:
That's a feature. I don't think it's going away. The problem of
accidental assignment is probably not very common.
-Steve
What is the benefit of this feature? I feel like D has quite a
few of such "features". I like my
On 6/30/20 12:22 PM, JN wrote:
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be permitted,
because it's easy to make a mistake
On Tue, Jun 30, 2020 at 04:22:57PM +, JN via Digitalmars-d-learn wrote:
> Spent some time debugging because I didn't notice it at first,
> essentially something like this:
>
> int[3] foo = [1, 2, 3];
> foo = 5;
> writeln(foo); // 5, 5, 5
>
> Why does such code compile? I don't think this
Spent some time debugging because I didn't notice it at first,
essentially something like this:
int[3] foo = [1, 2, 3];
foo = 5;
writeln(foo); // 5, 5, 5
Why does such code compile? I don't think this should be
permitted, because it's easy to make a mistake (when you wanted
foo[index] but
On Tuesday, 13 August 2019 at 06:39:24 UTC, a11e99z wrote:
On Tuesday, 13 August 2019 at 05:57:23 UTC, Mike Parker wrote:
On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
OT:
and again how to easy to google info about error/warning just
with one word "CS0108"
D can use attrs
On Tuesday, 13 August 2019 at 05:57:23 UTC, Mike Parker wrote:
On Tuesday, 13 August 2019 at 04:40:53 UTC, Chris Katko wrote:
I don't know if I'd call that shadowing. This is how it works
in Java, too. There's no such thing as a vtable for member
variables -- each class gets its own set and
;
writeln(c.x); //=2
writeln(array[0].x); //=1 //uses BASE's interface, yes,
//but why does the CHILD instance one exist at all?
}
It appears to be legal C++ as well but I can't imagine a
situation where you'd want to allow the HUGE risk of
shadowing/aliasing variables in an child class. Why
interface, yes,
//but why does the CHILD instance one exist at all?
}
It appears to be legal C++ as well but I can't imagine a
situation where you'd want to allow the HUGE risk of
shadowing/aliasing variables in an child class. Why is
inheritance shadowing allowed? Especially when in D you have
24 matches
Mail list logo
