On Monday, 21 October 2013 at 10:50:45 UTC, Chris wrote:
So the solution would be an additional layer that can be turned
on / off. Warnings like "unused variable" or "shadowing class
declaration" are quite useful. I don't see any other cases
where a warning would be nice (at the moment).
And
On Monday, October 21, 2013 12:50:44 Chris wrote:
> So the solution would be an additional layer that can be turned
> on / off. Warnings like "unused variable" or "shadowing class
> declaration" are quite useful. I don't see any other cases where
> a warning would be nice (at the moment).
Perhaps,
On Monday, 21 October 2013 at 09:36:48 UTC, Jonathan M Davis
wrote:
On Monday, October 21, 2013 11:24:06 Chris wrote:
But there you have this. But a function (in the same class)
like
void processInput() {
auto input = // ...
// 20 lines later
input = std.string.format("Hello %s!", som
On Monday, October 21, 2013 11:24:06 Chris wrote:
> But there you have this. But a function (in the same class) like
>
> void processInput() {
>auto input = // ...
>// 20 lines later
>input = std.string.format("Hello %s!", someString);
> }
>
> Why would one want to write code like thi
On Monday, 21 October 2013 at 09:05:58 UTC, Jonathan M Davis
wrote:
On Monday, October 21, 2013 10:37:57 Chris wrote:
Usually same-name
variables are only used in the constructor. Using them in other
places in the class is not recommendable
Well, that's up to the programmer, and plenty of folk
On Monday, October 21, 2013 10:37:57 Chris wrote:
> Usually same-name
> variables are only used in the constructor. Using them in other
> places in the class is not recommendable
Well, that's up to the programmer, and plenty of folks use them in places like
setters as well.
> but is it a good so
On Sunday, 20 October 2013 at 01:15:12 UTC, Jonathan M Davis
wrote:
On Saturday, October 19, 2013 18:50:16 Chris wrote:
A warning would be enough. The thing is I didn't want to give
it
the same name. It was meant to be the class variable but the
auto
was a leftover from a test. A warning would
On Saturday, October 19, 2013 18:50:16 Chris wrote:
> A warning would be enough. The thing is I didn't want to give it
> the same name. It was meant to be the class variable but the auto
> was a leftover from a test. A warning would have been nice, à la
> "do you really want this?". I would have se
On Friday, 18 October 2013 at 17:42:22 UTC, Jonathan M Davis
wrote:
On Friday, October 18, 2013 18:32:32 bearophile wrote:
Currently D doesn't give an error or warning if in a method you
declare a local variable with the same name of a instance
member.
This is indeed a source of bugs and I have
On 10/18/2013 08:26 PM, bearophile wrote:
That example of yours shows a possible intermediate rule: when in a
method you define a local variable that has the same name as an instance
member, then the instance member must be referred with the "this."
prefix inside that function. So that code will
On 10/18/2013 10:42 AM, Jonathan M Davis wrote:
> If you want to avoid the problem, then just don't name your local
variables
> the same as your member variables
Like OP, when I was bitten by this before, I had not intended to define
a local variable. It is too easy for the fingers to drop an
Jonathan M Davis:
The prime example is constructors.
this(int a, string b)
{
this.a = a;
this.b = b;
...
}
That example of yours shows a possible intermediate rule: when in
a method you define a local variable that has the same name as an
instance member, then the instance member must be
On Friday, October 18, 2013 18:32:32 bearophile wrote:
> Currently D doesn't give an error or warning if in a method you
> declare a local variable with the same name of a instance member.
> This is indeed a source of bugs and I have had similar problems.
> Generally D prefers to minimize the numbe
Chris:
I had a stupid bug:
class Base {
SomeStruct someStruct;
// ...
}
class BaseSub {
// ...
override {
public void doThis() {
auto someStruct = checkSomething("input"); // Bug is
here, of course,
// a leftover
from old cod
Ok. Here's a version to work with, if anyone wants to reproduce
the behavior.
import std.stdio;
void main() {
auto sub = new BaseSub();
sub.doSomething();
}
class Base {
SomeStruct someStruct;
this() {
}
public void doSo
I had a stupid bug:
class Base {
SomeStruct someStruct;
// ...
}
class BaseSub {
// ...
override {
public void doThis() {
auto someStruct = checkSomething("input"); // Bug is here,
of course,
// a leftover
from old code
}
16 matches
Mail list logo
