this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is not specified. I can see the counter arguments, but this is something the compiler should warn about.

Matthew wrote:

>        this(size_type dim, value_type value)
>        {
>            m_elements = new value_type[dim];
>
>            foreach(value_type element; m_elements)
>            {
>                element = value; //
>            }
>        }
>
>
>The assignment within the foreach loop has no effect, because inout is not
>specified. I can see the counter arguments, but this is something the
>compiler should warn about.
>
>  
>
An error should also probably also occur for:

+=
-=
~=
ect...

but then if element was an object, then an overloaded assignment operator would activate.

But your right this is a trap, that I've fallen into myself. Any particular reason why it's not inout by default?

PS - As we all know, be careful about using the word *warning* around big W ;)

> Matthew wrote:
>
> >        this(size_type dim, value_type value)
> >        {
> >            m_elements = new value_type[dim];
> >
> >            foreach(value_type element; m_elements)
> >            {
> >                element = value; //
> >            }
> >        }
> >
> >
> >The assignment within the foreach loop has no effect, because inout is
not
> >specified. I can see the counter arguments, but this is something the compiler should warn about.
> >
> >
> >
> An error should also probably also occur for:
>
> +=
> -=
> ~=
> ect...
>
> but then if element was an object, then an overloaded assignment operator would activate.
>
> But your right this is a trap, that I've fallen into myself. Any particular reason why it's not inout by default?
>
> PS - As we all know, be careful about using the word *warning* around big W ;)

It can't be an error because, as you say, it could be in a template, and using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is not the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.

it can't be an error because in the same way this would have to be an error then, too:

void func(int value) {
value = 10;
}

this is doable, and usable. it is a copy of the value passed in. in the same way, you get a copy of the object you iterate trough. wich is useful to be manipulateable..

In article <btdg9l$23pm$1@digitaldaemon.com>, Matthew says...
>
>> Matthew wrote:
>>
>> >        this(size_type dim, value_type value)
>> >        {
>> >            m_elements = new value_type[dim];
>> >
>> >            foreach(value_type element; m_elements)
>> >            {
>> >                element = value; //
>> >            }
>> >        }
>> >
>> >
>> >The assignment within the foreach loop has no effect, because inout is
>not
>> >specified. I can see the counter arguments, but this is something the compiler should warn about.
>> >
>> >
>> >
>> An error should also probably also occur for:
>>
>> +=
>> -=
>> ~=
>> ect...
>>
>> but then if element was an object, then an overloaded assignment operator would activate.
>>
>> But your right this is a trap, that I've fallen into myself. Any particular reason why it's not inout by default?
>>
>> PS - As we all know, be careful about using the word *warning* around big W ;)
>
>It can't be an error because, as you say, it could be in a template, and using operations that are valid for an in parameter.
>
>I know we've don't like warnings, but leaving it to a DLint program is not the answer. Look how successful that was for C, eh?
>
>I don't know what the answer is, other than not allowing an implicit in.
>
>
>

That wouldn't trouble me in the slightest.

I don't mean to be insulting to its fans, but I think the desire for such "conveniences" is juvenile. I'd be perfectly happy to type in for every in parameter.

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bte0tu$2u5c$1@digitaldaemon.com...
> it can't be an error because in the same way this would have to be an
error
> then, too:
>
> void func(int value) {
> value = 10;
> }
>
> this is doable, and usable. it is a copy of the value passed in. in the
same
> way, you get a copy of the object you iterate trough. wich is useful to be manipulateable..
>
> In article <btdg9l$23pm$1@digitaldaemon.com>, Matthew says...
> >
> >> Matthew wrote:
> >>
> >> >        this(size_type dim, value_type value)
> >> >        {
> >> >            m_elements = new value_type[dim];
> >> >
> >> >            foreach(value_type element; m_elements)
> >> >            {
> >> >                element = value; //
> >> >            }
> >> >        }
> >> >
> >> >
> >> >The assignment within the foreach loop has no effect, because inout is
> >not
> >> >specified. I can see the counter arguments, but this is something the compiler should warn about.
> >> >
> >> >
> >> >
> >> An error should also probably also occur for:
> >>
> >> +=
> >> -=
> >> ~=
> >> ect...
> >>
> >> but then if element was an object, then an overloaded assignment operator would activate.
> >>
> >> But your right this is a trap, that I've fallen into myself. Any particular reason why it's not inout by default?
> >>
> >> PS - As we all know, be careful about using the word *warning* around big W ;)
> >
> >It can't be an error because, as you say, it could be in a template, and using operations that are valid for an in parameter.
> >
> >I know we've don't like warnings, but leaving it to a DLint program is
not
> >the answer. Look how successful that was for C, eh?
> >
> >I don't know what the answer is, other than not allowing an implicit in.
> >
> >
> >
>
>

davepermen wrote:

>it can't be an error because in the same way this would have to be an error
>then, too:
>
>void func(int value) {
>value = 10;
>}
>
>this is doable, and usable. it is a copy of the value passed in. in the same
>way, you get a copy of the object you iterate trough. wich is useful to be
>manipulateable..
>  
>

If you did:

void func(int value) {
  value = 10;
  x = value;
}

That is, you use the value, then it shouldn't be considered an error.  But if you have:

void func(int value) {
value = 10;
}

Then your doing nothing with value.  It would be optimised away.

Anyway Matthew was suggesting a warning not error.


>In article <btdg9l$23pm$1@digitaldaemon.com>, Matthew says...
>  
>
>>>Matthew wrote:
>>>
>>>      
>>>
>>>>       this(size_type dim, value_type value)
>>>>       {
>>>>           m_elements = new value_type[dim];
>>>>
>>>>           foreach(value_type element; m_elements)
>>>>           {
>>>>               element = value; //
>>>>           }
>>>>       }
>>>>
>>>>
>>>>The assignment within the foreach loop has no effect, because inout is
>>>>        
>>>>
>>not
>>    
>>
>>>>specified. I can see the counter arguments, but this is something the
>>>>compiler should warn about.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>An error should also probably also occur for:
>>>
>>>+=
>>>-=
>>>~=
>>>ect...
>>>
>>>but then if element was an object, then an overloaded assignment
>>>operator would activate.
>>>
>>>But your right this is a trap, that I've fallen into myself. Any
>>>particular reason why it's not inout by default?
>>>
>>>PS - As we all know, be careful about using the word *warning* around
>>>big W ;)
>>>      
>>>
>>It can't be an error because, as you say, it could be in a template, and
>>using operations that are valid for an in parameter.
>>
>>I know we've don't like warnings, but leaving it to a DLint program is not
>>the answer. Look how successful that was for C, eh?
>>
>>I don't know what the answer is, other than not allowing an implicit in.
>>
>>
>>
>>    
>>
>
>
>  
>

then the compiler should spit out an "You're doing useless stuff, stoopid" error?

dunno.. i think he could spit that error out much more often:D

In article <bte1oj$2vfb$1@digitaldaemon.com>, J Anderson says...
>
>davepermen wrote:
>
>>it can't be an error because in the same way this would have to be an error then, too:
>>
>>void func(int value) {
>>value = 10;
>>}
>>
>>this is doable, and usable. it is a copy of the value passed in. in the same way, you get a copy of the object you iterate trough. wich is useful to be manipulateable..
>> 
>>
>
>If you did:
>
>void func(int value) {
>   value = 10;
>   x = value;
>}
>
>That is, you use the value, then it shouldn't be considered an error.  But if you have:
>
>void func(int value)
>{
>value = 10;
>}
>
>Then your doing nothing with value.  It would be optimised away.
>
>Anyway Matthew was suggesting a warning not error.
>
>
>>In article <btdg9l$23pm$1@digitaldaemon.com>, Matthew says...
>> 
>>
>>>>Matthew wrote:
>>>>
>>>> 
>>>>
>>>>>       this(size_type dim, value_type value)
>>>>>       {
>>>>>           m_elements = new value_type[dim];
>>>>>
>>>>>           foreach(value_type element; m_elements)
>>>>>           {
>>>>>               element = value; //
>>>>>           }
>>>>>       }
>>>>>
>>>>>
>>>>>The assignment within the foreach loop has no effect, because inout is
>>>>> 
>>>>>
>>>not
>>> 
>>>
>>>>>specified. I can see the counter arguments, but this is something the compiler should warn about.
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>An error should also probably also occur for:
>>>>
>>>>+=
>>>>-=
>>>>~=
>>>>ect...
>>>>
>>>>but then if element was an object, then an overloaded assignment operator would activate.
>>>>
>>>>But your right this is a trap, that I've fallen into myself. Any particular reason why it's not inout by default?
>>>>
>>>>PS - As we all know, be careful about using the word *warning* around big W ;)
>>>> 
>>>>
>>>It can't be an error because, as you say, it could be in a template, and using operations that are valid for an in parameter.
>>>
>>>I know we've don't like warnings, but leaving it to a DLint program is not the answer. Look how successful that was for C, eh?
>>>
>>>I don't know what the answer is, other than not allowing an implicit in.
>>>
>>>
>>>
>>> 
>>>
>>
>>
>> 
>>
>

davepermen wrote:

>then the compiler should spit out an "You're doing useless stuff, stoopid"
>error?
>
>dunno.. i think he could spit that error out much more often:D
>
>  
>
[Snip]

I would like it to cause an error when parameters aren't used. But that goes against the minimum obstructions to beginners principle, Walter has talked about before.

the problem is, its not something WRONG. its just something USELESS.

if the compiler should be able to detect usefulnes of code, it would have to be able to understand what you really want to program. in the end, it should then say "you want to code yet another first person shooter? thats useless.. error in compilation"

you get the idea..

for simple things, yes, we could get errors. but what if its more complex "dead code" ? does it still has to be able to report the "bug"?

errors only for code that is not understandable by the compiler or the running system, a.k.a. wrong. useless code can (but doesn't have to) get optimized away. but thats all about it.

In article <bteari$b7g$1@digitaldaemon.com>, J Anderson says...
>
>davepermen wrote:
>
>>then the compiler should spit out an "You're doing useless stuff, stoopid" error?
>>
>>dunno.. i think he could spit that error out much more often:D
>>
>> 
>>
>[Snip]
>
>I would like it to cause an error when parameters aren't used. But that goes against the minimum obstructions to beginners principle, Walter has talked about before.
>

J Anderson wrote:
> I would like it to cause an error when parameters aren't used. But that goes against the minimum obstructions to beginners principle, Walter has talked about before.

Does your average WinMain use all parameters?

Mine does not. And OpenWatcom warns me about it. If i could just turn them off one by one, and not as a class!

Now imagine it was an error! I would give up coding then.

-eye