www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My Kingdom For ...

reply Darryl Bleau <user example.net> writes:
opIndexConcat
opIndexConcatAssign

in D1, of course.

I would also potentially accept:

Returning static arrays from functions.

or, possibly:

!in
Feb 20 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Darryl Bleau" <user example.net> wrote in message 
news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


Sorry, no new language features in D1.

ref returns are planned in D2.  I'd also like !in but that issue's been 
discussed _so_ many times before..
Feb 20 2008
next sibling parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Wed, 20 Feb 2008 20:56:59 -0500, Jarrett Billingsley wrote:


 "Darryl Bleau" <user example.net> wrote in message
 news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


 
 Sorry, no new language features in D1.
 
 ref returns are planned in D2.  I'd also like !in but that issue's been
 discussed _so_ many times before..


Is there a FAQ about common feature requests?
Yes, that's a feature request, too. :)
Feb 20 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Moritz Warning wrote:

 On Wed, 20 Feb 2008 20:56:59 -0500, Jarrett Billingsley wrote:
 

 "Darryl Bleau" <user example.net> wrote in message
 news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


 Sorry, no new language features in D1.

 ref returns are planned in D2.  I'd also like !in but that issue's been
 discussed _so_ many times before..


 
 Is there a FAQ about common feature requests?
 Yes, that's a feature request, too. :)


And it's also a FAQ.  How 'bout that? :)

--bb
Feb 20 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fpin5l$121l$1 digitalmars.com...


 Is there a FAQ about common feature requests?
 Yes, that's a feature request, too. :)


 And it's also a FAQ.  How 'bout that? :)


My head just exploded from the recursion.
Feb 20 2008
prev sibling parent reply Darryl Bleau <user example.net> writes:
Jarrett Billingsley wrote:

 "Darryl Bleau" <user example.net> wrote in message 
 news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


 
 Sorry, no new language features in D1.
 


I know, and I knew when writing it that it was futile to ask. I suppose
I was more just venting my frustration that it seems that D1 was
released, and Walter said, 'go forth and create programs', which we did,
but now we turn around and say, hey, this D stuff is great, could we
just have a few minor changes? But, are denied. Seems Const and Enum are
much more important than helping with actual practical applications of
the current language.

Perhaps if we were around while D1 was still being developed.. but then,
we wouldn't have been using it in that state. Chicken, egg, and all that.

I like D, it's great, and I appreciate all the effort spent on it. I
just sort of wish D1 development continued on some level parallel to D2.
I wouldn't expect massive changes, but some minor additions would be
nice and would help out quite a lot with current usage.
Feb 21 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Darryl Bleau, el 21 de febrero a las 09:48 me escribiste:

 Jarrett Billingsley wrote:

 "Darryl Bleau" <user example.net> wrote in message 
 news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


 
 Sorry, no new language features in D1.
 


 
 I know, and I knew when writing it that it was futile to ask. I suppose
 I was more just venting my frustration that it seems that D1 was
 released, and Walter said, 'go forth and create programs', which we did,
 but now we turn around and say, hey, this D stuff is great, could we
 just have a few minor changes? But, are denied. Seems Const and Enum are
 much more important than helping with actual practical applications of
 the current language.


I agree. D1.0 looks more "abandoned" than "stable". A language should keep
moving even when it's stable, as long as the changes are backward
compatibles. That mean that a new syntax that was previosly forbiden or
new additions to the standard library could be done without affecting
stability.

If Walter don't have the time, maybe, again, it's time to name a
successor, someone who has the time to take over like Linus does with
the stable kernels.

I know this is extremely difficult with DMD being closed, but maybe he can
find a way.

For now, it's like there is no viable D Language, you have D1.0 wich is
broken (there are a lot of things specified in the specs that are not
implemented in D1.) and gets too little attention, or D2.0 that it's
continously evolving and getting huge changes.

I think D1.0 is good enough and deserves a little love to finally polish
all the rough corners and make it move forward in small and backward
compatible steps to be a nice, maintained and usable language.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Bulletproof... I Wish I Was
Feb 21 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Leandro Lucarella wrote:

 Darryl Bleau, el 21 de febrero a las 09:48 me escribiste:

 Jarrett Billingsley wrote:

 "Darryl Bleau" <user example.net> wrote in message 
 news:fphle3$20np$1 digitalmars.com...

 opIndexConcat
 opIndexConcatAssign

 in D1, of course.

 I would also potentially accept:

 Returning static arrays from functions.

 or, possibly:

 !in


 Sorry, no new language features in D1.


 I know, and I knew when writing it that it was futile to ask. I suppose
 I was more just venting my frustration that it seems that D1 was
 released, and Walter said, 'go forth and create programs', which we did,
 but now we turn around and say, hey, this D stuff is great, could we
 just have a few minor changes? But, are denied. Seems Const and Enum are
 much more important than helping with actual practical applications of
 the current language.


 
 I agree. D1.0 looks more "abandoned" than "stable". A language should keep
 moving even when it's stable, as long as the changes are backward
 compatibles. That mean that a new syntax that was previosly forbiden or
 new additions to the standard library could be done without affecting
 stability.
 
 If Walter don't have the time, maybe, again, it's time to name a
 successor, someone who has the time to take over like Linus does with
 the stable kernels.
 
 I know this is extremely difficult with DMD being closed, but maybe he can
 find a way.
 
 For now, it's like there is no viable D Language, you have D1.0 wich is
 broken (there are a lot of things specified in the specs that are not
 implemented in D1.) and gets too little attention, or D2.0 that it's
 continously evolving and getting huge changes.
 
 I think D1.0 is good enough and deserves a little love to finally polish
 all the rough corners and make it move forward in small and backward
 compatible steps to be a nice, maintained and usable language.
 


My sentiments exactly.
Well put.

--bb
Feb 21 2008
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:

 I think D1.0 is good enough and deserves a little love to finally polish
 all the rough corners and make it move forward in small and backward
 compatible steps to be a nice, maintained and usable language.


The frontend is open source; care to volunteer?
Feb 21 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
Christopher Wright, el 21 de febrero a las 22:33 me escribiste:

 Leandro Lucarella wrote:

I think D1.0 is good enough and deserves a little love to finally polish
all the rough corners and make it move forward in small and backward
compatible steps to be a nice, maintained and usable language.


 
 The frontend is open source; care to volunteer?


Yes, but the only problem here is not the source code. If I decide to
change the frontend to admit, for example, !in, but Walter don't want to
include it on DMD (which will mean that GDC probably will not follow),
nothing will change. Other posibility will be to fork the language
specification, but I don't know if that's even possible because of the
licensing issues. Or one could just implemente that stuff in GDC
documenting just the extra features.

Either way, I don't think it's very good for the language, we already have
to problems of phobos vs. tango to add DMD vs GDC/whatever.

I think that, to be successful, it have to be some "official" support so
a fork is not necessary.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Does humor belong in music? -- Frank Zappa
Yes it does, Frank. -- Kevin Johansen
Feb 22 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Leandro Lucarella wrote:

 Christopher Wright, el 21 de febrero a las 22:33 me escribiste:

 Leandro Lucarella wrote:

 I think D1.0 is good enough and deserves a little love to finally polish
 all the rough corners and make it move forward in small and backward
 compatible steps to be a nice, maintained and usable language.


 The frontend is open source; care to volunteer?


 
 Yes, but the only problem here is not the source code. If I decide to
 change the frontend to admit, for example, !in, but Walter don't want to
 include it on DMD (which will mean that GDC probably will not follow),
 nothing will change. Other posibility will be to fork the language
 specification, but I don't know if that's even possible because of the
 licensing issues. Or one could just implemente that stuff in GDC
 documenting just the extra features.


It comes down to a popularity contest, and DMD is way ahead.

But let's say the fork just started as a testbed for bug fixes and the 
like. That'd probably garner more attention than one going for new 
features. And maybe porting some minor changes in D2 to D1.
Feb 22 2008
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
/me boos !in again.

Walter's argument against !in makes perfect sense, and nobody ever 
acknowledges that. 'in' is not a boolean operation, and it wouldn't be 
good for 'in' to return a pointer and '!in' to return a bool. That's 
just silly.

  - Gregor Richards
Feb 20 2008
next sibling parent reply Michiel Helvensteijn <nomail please.com> writes:
Gregor Richards wrote:


 /me boos !in again.
 
 Walter's argument against !in makes perfect sense, and nobody ever
 acknowledges that. 'in' is not a boolean operation, and it wouldn't be
 good for 'in' to return a pointer and '!in' to return a bool. That's
 just silly.


It's silly that 'in' does not return a bool. 'in' and '!in' make perfect
sense together as boolean operators (as in set theory).

Of course, you want to be able to get the pointer too, but I would suggest a
library function for that.

That's readability.

-- 
Michiel
Feb 21 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Gregor Richards:

 Walter's argument against !in makes perfect sense, and nobody ever
 acknowledges that. 'in' is not a boolean operation, and it wouldn't be
 good for 'in' to return a pointer and '!in' to return a bool. That's
 just silly.


"in" and "!in" may return both bools.
Another solution is to think "in" as an operator, and "!in" as two operators,
where ! negates the result of the precedent "in", where "in" returns a pointer.
I don't see this as silly :-)

Bye,
bearophile
Feb 21 2008
parent reply Darryl Bleau <user example.net> writes:
bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two operators,
where ! negates the result of the precedent "in", where "in" returns a pointer.
I don't see this as silly :-)


I should have read this first. Yes, that's exactly what I would like.
Feb 21 2008
parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:


 bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two
 operators, where ! negates the result of the precedent "in", where "in"
 returns a pointer. I don't see this as silly :-)


 
 I should have read this first. Yes, that's exactly what I would like.


Fwiw:
"is" may be no boolean operator, but "!" is a boolean operator.
Hence, "!is" can be boolean operator the same way as "=" is not a boolean 
operator, but "!=" is.
Feb 21 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Moritz Warning wrote:

 On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:
 

 bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two
 operators, where ! negates the result of the precedent "in", where "in"
 returns a pointer. I don't see this as silly :-)


 I should have read this first. Yes, that's exactly what I would like.


 
 Fwiw:
 "is" may be no boolean operator, but "!" is a boolean operator.
 Hence, "!is" can be boolean operator the same way as "=" is not a boolean 
 operator, but "!=" is.


Did you man "in"? "is" is a boolean operator.
Feb 21 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:

 Moritz Warning wrote:

 On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:


 bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two
 operators, where ! negates the result of the precedent "in", where "in"
 returns a pointer. I don't see this as silly :-)


 I should have read this first. Yes, that's exactly what I would like.


 Fwiw:
 "is" may be no boolean operator, but "!" is a boolean operator.
 Hence, "!is" can be boolean operator the same way as "=" is not a 
 boolean operator, but "!=" is.


 
 Did you man "in"? "is" is a boolean operator.


I think Bill Clinton had something to say about this subject...
:-)
--bb
Feb 21 2008
prev sibling parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Thu, 21 Feb 2008 16:24:11 -0800, Robert Fraser wrote:


 Moritz Warning wrote:

 On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:
 

 bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two
 operators, where ! negates the result of the precedent "in", where
 "in" returns a pointer. I don't see this as silly :-)


 I should have read this first. Yes, that's exactly what I would like.


 
 Fwiw:
 "is" may be no boolean operator, but "!" is a boolean operator. Hence,
 "!is" can be boolean operator the same way as "=" is not a boolean
 operator, but "!=" is.


 
 Did you man "in"? "is" is a boolean operator.


Yes, I meant "in", not "is". - memory corruption. ;)

"=" is no boolean operator, but "!=" is.
The reason for not having "!in" is weak, imho.
Feb 21 2008
parent reply Gregor Richards <Richards codu.org> writes:
Moritz Warning wrote:

 On Thu, 21 Feb 2008 16:24:11 -0800, Robert Fraser wrote:
 

 Moritz Warning wrote:

 On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:


 bearophile wrote:

 Another solution is to think "in" as an operator, and "!in" as two
 operators, where ! negates the result of the precedent "in", where
 "in" returns a pointer. I don't see this as silly :-)


 I should have read this first. Yes, that's exactly what I would like.


 Fwiw:
 "is" may be no boolean operator, but "!" is a boolean operator. Hence,
 "!is" can be boolean operator the same way as "=" is not a boolean
 operator, but "!=" is.


 Did you man "in"? "is" is a boolean operator.


 
 Yes, I meant "in", not "is". - memory corruption. ;)
 
 "=" is no boolean operator, but "!=" is.
 The reason for not having "!in" is weak, imho.


!= is not the opposite of =, it's the opposite of ==.

  - Gregor Richards
Feb 22 2008
next sibling parent Darryl Bleau <user example.net> writes:
Gregor Richards wrote:

 != is not the opposite of =, it's the opposite of ==.
 
  - Gregor Richards


In the interest of supreme correctness, shouldn't that be !== then?

/cheers :)
Feb 22 2008
prev sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Gregor Richards wrote:

 Moritz Warning wrote:

 "=" is no boolean operator, but "!=" is.
 The reason for not having "!in" is weak, imho.


 
 != is not the opposite of =, it's the opposite of ==.


Yay, lets introduce !n instead!
Feb 23 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Alexander Panek" <alexander.panek brainsware.org> wrote in message 
news:fppo5s$11v6$1 digitalmars.com...

 Gregor Richards wrote:

 Moritz Warning wrote:

 "=" is no boolean operator, but "!=" is.
 The reason for not having "!in" is weak, imho.


 != is not the opposite of =, it's the opposite of ==.


 Yay, lets introduce !n instead!


VOTE PLUS EQUALS A MILLION
Feb 23 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Michiel Helvensteijn <nomail please.com> wrote:

 It's silly that 'in' does not return a bool.


Huh? But I don't want it to return a bool. If it retured a bool, I
wouldn't be able to do

    auto p = key in aa;
    if (p is null)
    {
        /* do something */
    }
    else
    {
        return *p;
    }

Without that ability, you'd have to do a double-lookup!
Feb 21 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 21/02/2008, Michiel Helvensteijn <nomail please.com> wrote:

 It's silly that 'in' does not return a bool.


 
 Huh? But I don't want it to return a bool. If it retured a bool, I
 wouldn't be able to do
 
     auto p = key in aa;
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }
 
 Without that ability, you'd have to do a double-lookup!


I think the best solution is the one in .Net:

object value;
if (aa.TryGetValue(key, out value)) {
   // Key found, value may be null
} else {
   // Key not found
}
Feb 21 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Ary Borenszweig wrote:

 Janice Caron escribió:

 On 21/02/2008, Michiel Helvensteijn <nomail please.com> wrote:

 It's silly that 'in' does not return a bool.


 Huh? But I don't want it to return a bool. If it retured a bool, I
 wouldn't be able to do

     auto p = key in aa;
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }

 Without that ability, you'd have to do a double-lookup!


 
 I think the best solution is the one in .Net:
 
 object value;
 if (aa.TryGetValue(key, out value)) {
   // Key found, value may be null
 } else {
   // Key not found
 }


That would be better if the language allowed:
// value not defined
if (aa.TryGetValue(key, out object value))
{
   // ok, now I can use value
}
else
{
   // Key not found
}
Feb 21 2008
prev sibling next sibling parent Michiel Helvensteijn <nomail please.com> writes:
Janice Caron wrote:


 On 21/02/2008, Michiel Helvensteijn <nomail please.com> wrote:
 

 It's silly that 'in' does not return a bool.


 
 Huh? But I don't want it to return a bool. If it retured a bool, I
 wouldn't be able to do
 
     auto p = key in aa;
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }
 
 Without that ability, you'd have to do a double-lookup!


In those cases you use that library function I mentioned. It would do the
exact thing 'in' does now.

When I read: key in aa, I understand: key is member of aa. Like the operator
in set theory (looks like an epsilon). Apparently I'm not alone in this
if !in has been requested so often.

-- 
Michiel
Feb 21 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Janice Caron, el 21 de febrero a las 15:38 me escribiste:

 On 21/02/2008, Michiel Helvensteijn <nomail please.com> wrote:

 It's silly that 'in' does not return a bool.


 
 Huh? But I don't want it to return a bool. If it retured a bool, I
 wouldn't be able to do
 
     auto p = key in aa;
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }
 
 Without that ability, you'd have to do a double-lookup!


What about the Python-way:

     auto p = aa.get(key);
     if (p is null)
     {
         /* do something */
     }
     else
     {
         return *p;
     }

And leave in as a bool operator?
get could take an optional parameter which is the value you want it to
return if the key is not present.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
PROTESTA EN PLAZA DE MAYO: MUSICO SE COSIO LA BOCA
	-- Crónica TV
Feb 21 2008
prev sibling next sibling parent Darryl Bleau <user example.net> writes:
Gregor Richards wrote:

 /me boos !in again.
 
 Walter's argument against !in makes perfect sense, and nobody ever
 acknowledges that. 'in' is not a boolean operation, and it wouldn't be
 good for 'in' to return a pointer and '!in' to return a bool. That's
 just silly.
 


I don't expect it to return a boolean, I just expect '!' to perform a
not operation. That is, I would expect that:

(a !in b)

Would behave the same as:

(!(a in b))

'a in b' can still return the pointer fine, that makes perfect sense.
Feb 21 2008
prev sibling parent reply Matti Niemenmaa <see_signature for.real.address> writes:
Gregor Richards wrote:

 /me boos !in again.
 
 Walter's argument against !in makes perfect sense, and nobody ever 
 acknowledges that. 'in' is not a boolean operation, and it wouldn't be 
 good for 'in' to return a pointer and '!in' to return a bool. That's 
 just silly.


Why not make it generic? I hereby propose that "a !op b" be always equivalent
to 
"(a op b) !is cast(typeof(a op b))0". (Not just "!(a op b)" because I'm not
sure 
whether that works in all cases, but I think this should.)

Imagine the increased clarity:

return *a !- *b ? *a!**b : foo!(int)!&a;

Compare this to the ludicrously verbose:

return *a - *b == 0 ? *a * *b == 0 : (foo!(int) & a) !is null;

We even sidestep the problem of "a & b == 0" being parsed as "a & (b == 0)"!

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 21 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Matti Niemenmaa" <see_signature for.real.address> wrote in message 
news:fpkebq$274u$1 digitalmars.com...


 Imagine the increased clarity:

 return *a !- *b ? *a!**b : foo!(int)!&a;


This is clear?

News to me!
Feb 21 2008
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
On Thu, 21 Feb 2008, Jarrett Billingsley wrote:


 "Matti Niemenmaa" <see_signature for.real.address> wrote in message
 news:fpkebq$274u$1 digitalmars.com...


 Imagine the increased clarity:

 return *a !- *b ? *a!**b : foo!(int)!&a;


 This is clear?

 News to me!


Coding in high level languages with customizable operators tends to leave 
a mark ;)
Feb 21 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Jari-Matti Mäkelä wrote:

 
 
 On Thu, 21 Feb 2008, Jarrett Billingsley wrote:
 

 "Matti Niemenmaa" <see_signature for.real.address> wrote in message
 news:fpkebq$274u$1 digitalmars.com...


 Imagine the increased clarity:

 return *a !- *b ? *a!**b : foo!(int)!&a;


 This is clear?

 News to me!


 
 Coding in high level languages with customizable operators tends to 
 leave a mark ;)


You were being serious? I need to rewire my sarcasm detector.
Feb 21 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Darryl Bleau wrote:

 opIndexConcat
 opIndexConcatAssign


Maybe it's the 5 AM thing, but I'm feeling pretty stupid right now. What 
would these do?


 in D1, of course.


Not happening. D2, maybe.


 I would also potentially accept:
 
 Returning static arrays from functions.


Wrap it in a struct. What's your use case for this, anyway?


 or, possibly:
 
 !in


Gregor's post sums up my thoughts on the issue.
Feb 21 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fpjuh5$uai$1 digitalmars.com...

 Darryl Bleau wrote:

 opIndexConcat
 opIndexConcatAssign




// Contrived, but shows the issue.
struct IntArray
{
    int[] mData;

    int opIndex(size_t idx)
    {
        return mData[idx];
    }
}

int[] realArray = [1, 2, 3];
realArray[0]++; // now contains [2, 2, 3]

IntArray a;
a.mData = [1, 2, 3];
a[0]++; // FAIL

In other words without these opIndexSomethingAssign overloads or ref returns 
it's impossible to make a user container type behave just like a built-in 
one.

(as an aside MiniD solves this by defining "a[0]++" to be "temp = a[0]; 
temp++; a[0] = temp;" but that's beside the point.)
Feb 21 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:fpjuh5$uai$1 digitalmars.com...

 Darryl Bleau wrote:

 opIndexConcat
 opIndexConcatAssign




 
 // Contrived, but shows the issue.
 struct IntArray
 {
     int[] mData;
 
     int opIndex(size_t idx)
     {
         return mData[idx];
     }
 }
 
 int[] realArray = [1, 2, 3];
 realArray[0]++; // now contains [2, 2, 3]
 
 IntArray a;
 a.mData = [1, 2, 3];
 a[0]++; // FAIL
 
 In other words without these opIndexSomethingAssign overloads or ref returns 
 it's impossible to make a user container type behave just like a built-in 
 one.
 
 (as an aside MiniD solves this by defining "a[0]++" to be "temp = a[0]; 
 temp++; a[0] = temp;" but that's beside the point.) 


Ah, I see! Ref returns are a more general & overall happier solution, IMO.
Feb 21 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:fpjuh5$uai$1 digitalmars.com...

 Darryl Bleau wrote:

 opIndexConcat
 opIndexConcatAssign




 
 // Contrived, but shows the issue.
 struct IntArray
 {
     int[] mData;
 
     int opIndex(size_t idx)
     {
         return mData[idx];
     }
 }
 
 int[] realArray = [1, 2, 3];
 realArray[0]++; // now contains [2, 2, 3]
 
 IntArray a;
 a.mData = [1, 2, 3];
 a[0]++; // FAIL
 
 In other words without these opIndexSomethingAssign overloads or ref returns 
 it's impossible to make a user container type behave just like a built-in 
 one.
 
 (as an aside MiniD solves this by defining "a[0]++" to be "temp = a[0]; 
 temp++; a[0] = temp;" but that's beside the point.) 


So it sounds like what you actually meant was opIndexAddAssign.
opIndexConcatAssign would be like a[0]~=10.

But anyway, generally going that route would require creating a whole 
slew of new operators, basically an opIndex version of every current 
op***Assign operator.  That *would* give a class designer fine grained 
control over what was allowed and not allowed, but it's probably overkill.

On the other hand, the "return a reference" solution also has drawbacks 
in that it exposes the implementation and gives up control over the 
element.  Consider for instance an array wrapper where you want to track 
every modification to every element.  Currently you can do that quite 
easily by making opIndexAssign the only means of modifying the data. 
But then you can't do things like a[10] += 5.   So I think there's a 
place for the solution you use in MiniD as well.  Even after reference 
returns become possible I'd be happy to see the compiler use that trick 
in cases where there is no reference-returning version of opIndex defined.

--bb
Feb 21 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:

 On the other hand, the "return a reference" solution also has drawbacks 
 in that it exposes the implementation and gives up control over the 
 element.  Consider for instance an array wrapper where you want to track 
 every modification to every element.  Currently you can do that quite 
 easily by making opIndexAssign the only means of modifying the data. But 
 then you can't do things like a[10] += 5.   So I think there's a place 
 for the solution you use in MiniD as well.  Even after reference returns 
 become possible I'd be happy to see the compiler use that trick in cases 
 where there is no reference-returning version of opIndex defined.
 
 --bb



opDot on structs, though.
Feb 21 2008
prev sibling parent Darryl Bleau <user example.net> writes:
Robert Fraser wrote:

 Darryl Bleau wrote:

 opIndexConcat
 opIndexConcatAssign


 
 Maybe it's the 5 AM thing, but I'm feeling pretty stupid right now. What
 would these do?


This was answered and is what I would use them for. To create user
containers that operate like built-in ones. I know that there are other,
more extensible ways to do this (left references) but I'm just looking
for something a little less involved, to help with D1 programming.

It would seem to me that if there is already opIndexAssign that adding a
few others like these should probably not be a ton of effort, though
that is just an educated guess and I could be wrong. But if it weren't a
lot of effort, and only cost a few extra lines of code, it would be nice
to have.



 Returning static arrays from functions.


 
 Wrap it in a struct. What's your use case for this, anyway?


My particular use case is a logger which can properly use lazy format
parameters without having to do something like log.info("{}"[],
"blah"[]);, which works, and preserves laziness, but isn't exactly friendly.


 or, possibly:

 !in


 
 Gregor's post sums up my thoughts on the issue.


(!(a in b)) == (a !in b) would be all I'm asking.


Don't get me wrong though, I understand completely that none of this
will ever happen. I just wish it could. :)
Feb 21 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
Please please please, can we have this either not compile, or else do a 
reference compare:

class C {}

C x = null;
x != null;
x == null;

I just got bit by this again today!  I hate this stupid "feature".  The 
result is always a segmentation fault, with no information on where it 
happened.  I probably have more of these in my code that just haven't 
executed yet.

Before people respond saying "you need to use is or !is", um yeah I know.  I 
just can't get my brain to re-learn how to compare to null, when every other 
language on the planet does it with ==.  Even if the compiler complained, I 
wouldn't mind.

If ever there was a subtle bug that could easily be fixed by a compiler 
update, and absolutely wouldn't affect any existing valid code, this is it.

-Steve
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 Please please please, can we have this either not compile, or else do a
  reference compare:

  class C {}

  C x = null;
  x != null;
  x == null;


Yeah, but then how would you call opEquals?
Feb 21 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote

 On 21/02/2008, Steven Schveighoffer wrote:

 Please please please, can we have this either not compile, or else do a
  reference compare:

  class C {}

  C x = null;
  x != null;
  x == null;


 Yeah, but then how would you call opEquals?


Simple.  If you are not doing == null, then call opEquals.  And I don't mean 
make the check at runtime, I mean the compiler should check if you are doing 
== null with the keyword null, then either throw an error or do the bit 
compare.  Anything else, call opEquals.  It's one of those little hackish 
exceptions to the rule that would make life soo much easier, and would not 
impact anyone adversely.

-Steve
Feb 21 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Steven Schveighoffer wrote:

 "Janice Caron" wrote

 On 21/02/2008, Steven Schveighoffer wrote:

 Please please please, can we have this either not compile, or else do a
  reference compare:

  class C {}

  C x = null;
  x != null;
  x == null;


 Yeah, but then how would you call opEquals?


 
 Simple.  If you are not doing == null, then call opEquals.  And I don't mean 
 make the check at runtime, I mean the compiler should check if you are doing 
 == null with the keyword null, then either throw an error or do the bit 
 compare.  Anything else, call opEquals.  It's one of those little hackish 
 exceptions to the rule that would make life soo much easier, and would not 
 impact anyone adversely.


I'd vote enthusiastically for issuing a warning, but I don't like the 
idea of changing behavior just for that one special case.
For instance what would this do?

C Null = null;
if (x != Null) {...}

Seems pretty confusing to me if that does something different from x!=null.

--bb
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 I'd vote enthusiastically for issuing a warning, but I don't like the
  idea of changing behavior just for that one special case.


I'd be inclined to agree, but for the fact that D doesn't have warnings.

So, you could say, second best option, make it a compile error.

    if (c == null) // ERROR

Anyone see any problem with that? Sure, it'd be annoying, but I think
it would a lot /less/ annoying than a crash at run time.
Feb 21 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:

 On 21/02/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 I'd vote enthusiastically for issuing a warning, but I don't like the
  idea of changing behavior just for that one special case.


 
 I'd be inclined to agree, but for the fact that D doesn't have warnings.
 
 So, you could say, second best option, make it a compile error.
 
     if (c == null) // ERROR
 
 Anyone see any problem with that? Sure, it'd be annoying, but I think
 it would a lot /less/ annoying than a crash at run time.


What's that -w flag do?  Wouldn't it be appropriate there?

--bb
Feb 21 2008
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 21/02/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 I'd vote enthusiastically for issuing a warning, but I don't like the
  idea of changing behavior just for that one special case.


 
 I'd be inclined to agree, but for the fact that D doesn't have warnings.
 
 So, you could say, second best option, make it a compile error.
 
     if (c == null) // ERROR
 
 Anyone see any problem with that?


I did it in Descent as a warning, but then it appeared in lot of places 
in phobos, so that definitely doesn't work (I removed it from Descent). 
It must only be an error if c is a class reference. If it's a pointer, 
it's ok. Any other case?
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  It must only be an error if c is a class reference. If it's a pointer,
  it's ok


Why? if (p is null) works for pointers too, and in template
programming, the compiler doesn't always know what p is anyway.
Feb 21 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  It must only be an error if c is a class reference. If it's a pointer,
  it's ok


 
 Why? if (p is null) works for pointers too


That's what I said: "If it's a pointer, it's ok" (don't show a 
warning/error). Or are you saying something completely different?

, and in template

 programming, the compiler doesn't always know what p is anyway.


Templates aren't evaluated until they are instantiated, so the compiler 
can do the same check only in instantiations.
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  It must only be an error if c is a class reference. If it's a pointer,




  >>  it's ok


 Why? if (p is null) works for pointers too


 That's what I said: "If it's a pointer, it's ok" (don't show a
  warning/error). Or are you saying something completely different?


I guess I was. I suppose I was saying, let's make "== null" illegal
for /all/ types. "== null" just isn't needed, because in /all/ cases,
"is null" works.
Feb 21 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Janice Caron escribió:

 On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  It must only be an error if c is a class reference. If it's a pointer,




  >>  it's ok


 Why? if (p is null) works for pointers too


 That's what I said: "If it's a pointer, it's ok" (don't show a
  warning/error). Or are you saying something completely different?


 
 I guess I was. I suppose I was saying, let's make "== null" illegal
 for /all/ types. "== null" just isn't needed, because in /all/ cases,
 "is null" works.


That's even better than an error. :-)

But programmers are used to use "==" for comparisons with null... 
Another alternative would be for the compiler to rewrite "== null" as 
"is null", always.
Feb 21 2008
next sibling parent Derek Parnell <derek nomail.afraid.org> writes:
On Thu, 21 Feb 2008 23:55:29 +0100, Ary Borenszweig wrote:


 I guess I was. I suppose I was saying, let's make "== null" illegal
 for /all/ types. "== null" just isn't needed, because in /all/ cases,
 "is null" works.


 
 That's even better than an error. :-)
 
 But programmers are used to use "==" for comparisons with null... 
 Another alternative would be for the compiler to rewrite "== null" as 
 "is null", always.


For what its worth, I'm also in the camp that feels that "== null" and "is
null" should be treated semantically the same by the language. I realize
that his would add a bit of complexity in a compiler that automatically
translates "==" into an opEquals() call.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 9:58:03 AM
Feb 21 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  But programmers are used to use "==" for comparisons with null...
  Another alternative would be for the compiler to rewrite "== null" as
  "is null", always.


Yep. That works for me too.

Of course, what I'd /really/ prefer is a runtime check (in debug
builds only, of course) for all null dereferences. I see it as
basically the same as array bounds checking - for speed, you don't
want it in a final release, but during development, you sacrifice the
speed and let the compiler help out. That would be useful, because not
only would it catch ==null, but it would also catch .member and
.func(), and you'd get a nice error message telling what line of what
file threw the exception.

And while we're on the subject of random falling over, am I the only
one who gets infuriated by the occasional "Win32 Exception" halting a
program with no further explanation? They happen when the flow of
execution hits the bottom of a function without returning, when it's
supposed to return something. I'm surprised we can't catch those at
compile time, but even a nice D Exception throw at runtime (...again,
in a debug build only...) would be useful.
Feb 21 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message 
news:mailman.47.1203635455.2351.digitalmars-d puremagic.com...


 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


Except that it _does_ throw an exception to that effect in a debug build. 
God, have you even _used_ D?
Feb 21 2008
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fpl0sc$hbe$1 digitalmars.com...

 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.47.1203635455.2351.digitalmars-d puremagic.com...


 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


 Except that it _does_ throw an exception to that effect in a debug build. 
 God, have you even _used_ D?


Sorry for being a bit harsh.  I'm just defensive when people criticize D for 
not doing things it should when it does do them.
Feb 21 2008
prev sibling next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 21/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message
  God, have you even _used_ D?


I've written bits of Phobos, does that count?

D /does/ fall over in the circumstance I described. The only error
message you see on the console is "Win32 Exception". No filename. No
line number. It happened to me only yesterday, using D2.010.
Feb 21 2008
next sibling parent Dan <murpsoft hotmail.com> writes:
Janice Caron Wrote:


 On 21/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message
  God, have you even _used_ D?


 
 I've written bits of Phobos, does that count?
 
 D /does/ fall over in the circumstance I described. The only error
 message you see on the console is "Win32 Exception". No filename. No
 line number. It happened to me only yesterday, using D2.010.


Janice Caron Wrote:


 On 21/02/2008, Ary Borenszweig <ary esperanto.org.ar> wrote:

  But programmers are used to use "==" for comparisons with null...
  Another alternative would be for the compiler to rewrite "== null" as
  "is null", always.


 
 Yep. That works for me too.
 
 Of course, what I'd /really/ prefer is a runtime check (in debug
 builds only, of course) for all null dereferences. I see it as
 basically the same as array bounds checking - for speed, you don't
 want it in a final release, but during development, you sacrifice the
 speed and let the compiler help out. That would be useful, because not
 only would it catch ==null, but it would also catch .member and
 .func(), and you'd get a nice error message telling what line of what
 file threw the exception.
 
 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


Yes it does do that.  Yes it's annoying.  Yes, there's a way to catch those
exceptions using... try/catch or scope(error) or scope(exit) and figuring it
out.

No, you're not the only one who finds the limited error messages annoying. 
It's about the only time I get rage on the machine - when I get unidentified
compiler errors.  I would much prefer a *real* debugger like IDA Pro if it had
hooks to bind it to another program's GP faults and other such errors.

Lately I've been writing Walnut in assembler and leveraging some OS function to
hook one of my functions as my error handler with the OS.  I use the function
to dump all the registers - though it would be nice to see a few items of the
stack too.

It makes debugging that kind of crap alot easier.  Assembler allows anything
the machine can do - which means your code can screw up in more ways than a
compiled language can.

It also means I can write a lexer in under 2.5kb of machine code that runs 8
times as fast as a D compiled switch-based lexer.  The next Walnut will blaze. 
: )
Feb 21 2008
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Fri, 22 Feb 2008 00:04:18 +0000, Janice Caron wrote:


 On 21/02/2008, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message
  God, have you even _used_ D?


 
 I've written bits of Phobos, does that count?


Ah ... well that accounts for some things now ... ;-) (Just kidding)
 

 D /does/ fall over in the circumstance I described. The only error
 message you see on the console is "Win32 Exception". No filename. No
 line number. It happened to me only yesterday, using D2.010.


Compile with the "-w" switch. It checks for 'missing' return paths.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 1:14:13 PM
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 22/02/2008, Derek Parnell <derek nomail.afraid.org> wrote:

 Compile with the "-w" switch. It checks for 'missing' return paths.


Ah great! Thanks. That will help a lot.

I thought D didn't have warnings, but obviously I was wrong.

It's a shame you can't /selectively/ enable warnings, because I don't
actually want to be warned about "length" shadowing. Still - it's
better than it's being an error. In general, I'd prefer that /all/
shadowing should be allowed. But that's another debate.

Anyway, thanks for the info. Will definitely be using -w from now on.
Feb 21 2008
parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

 On 22/02/2008, Derek Parnell <derek nomail.afraid.org> wrote:

 Compile with the "-w" switch. It checks for 'missing' return paths.


 
 Ah great! Thanks. That will help a lot.
 
 I thought D didn't have warnings, but obviously I was wrong.
 
 It's a shame you can't /selectively/ enable warnings, because I don't
 actually want to be warned about "length" shadowing. Still - it's
 better than it's being an error. In general, I'd prefer that /all/
 shadowing should be allowed. But that's another debate.
 
 Anyway, thanks for the info. Will definitely be using -w from now on.


Really, 'missing return value' should be an error, not a warning. Unfortunately 
-w is horribly broken. It generates some nasty spurious errors. For example, it 
won't let you perform a bitwise operation on anything other than an int.

short a;
short b = a | a; // won't compile with -w !!!!
Feb 22 2008
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 22 Feb 2008 22:27:34 +0100, Don Clugston wrote:


 Janice Caron wrote:

 On 22/02/2008, Derek Parnell <derek nomail.afraid.org> wrote:

 Compile with the "-w" switch. It checks for 'missing' return paths.


 
 Ah great! Thanks. That will help a lot.
 
 I thought D didn't have warnings, but obviously I was wrong.
 
 It's a shame you can't /selectively/ enable warnings, because I don't
 actually want to be warned about "length" shadowing. Still - it's
 better than it's being an error. In general, I'd prefer that /all/
 shadowing should be allowed. But that's another debate.
 
 Anyway, thanks for the info. Will definitely be using -w from now on.


 
 Really, 'missing return value' should be an error, not a warning.
Unfortunately 
 -w is horribly broken. 


The "-w" does not mean "warning" in D. Walter does not believe in warnings.
In D, it means an optional error check, that is to say, one can optionally
choose to check for certain types of errors that are not checked for
without the "-w" switch. I think these are optional because there is some
debate over whether these things are actually errors or not.

The message text says 'warning' but the compiler treats them as errors
anyway.


 It generates some nasty spurious errors. For example, it 
 won't let you perform a bitwise operation on anything other than an int.
 
 short a;
 short b = a | a; // won't compile with -w !!!!


Actually that turns out not to be the case. The 'warning/error' message in
this situatation informs the coder that there is a potential loss of
information when assigning a larger datatype to a smaller one. 

"warning - test.d(4): Error: implicit conversion of expression
 (cast(int)a | cast (int)a) of type int to short can cause
 loss of data"

The real problem with this is that D decides to convert your 'short' values
to 'int' before doing the bitwise operation, leaving you with an 'int'
value to squeeze back into a 'short'. Now you and I know that this is a
redundant operation (converting to 'int') and that the high-end bits will
be zeroes anyway so that there is no loss of information. But DMD is not
that smart yet.

The 'warning' message is a valid one, in the general sense. For example
this code here gives a similar message ...

void main(string[] args)
{
  short argc = args.length;
}

Even though we all know that we are not going to have 2^32 command line
arguments to the program. 

The proper coding style to get the results you want is to tell the
compiler, and other readers of your code, that you "know what you are doing
so don't get upset"...

 short a;
 short b = cast(short)(a | a);

 short argc = cast(short)args.length;

These do not give 'warning' messages now.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 22 2008
parent reply Don Clugston <dac nospam.com.au> writes:
Derek Parnell wrote:

 On Fri, 22 Feb 2008 22:27:34 +0100, Don Clugston wrote:
 

 Janice Caron wrote:

 On 22/02/2008, Derek Parnell <derek nomail.afraid.org> wrote:

 Compile with the "-w" switch. It checks for 'missing' return paths.


 Ah great! Thanks. That will help a lot.

 I thought D didn't have warnings, but obviously I was wrong.

 It's a shame you can't /selectively/ enable warnings, because I don't
 actually want to be warned about "length" shadowing. Still - it's
 better than it's being an error. In general, I'd prefer that /all/
 shadowing should be allowed. But that's another debate.

 Anyway, thanks for the info. Will definitely be using -w from now on.


 Really, 'missing return value' should be an error, not a warning.
Unfortunately 
 -w is horribly broken. 


 
 The "-w" does not mean "warning" in D. Walter does not believe in warnings.


Nor do I.


 In D, it means an optional error check, that is to say, one can optionally
 choose to check for certain types of errors that are not checked for
 without the "-w" switch. I think these are optional because there is some
 debate over whether these things are actually errors or not.


The problem is that some of them have a >90% chance of being a bug, whereas 
others (such as the one I mentioned) have a ZERO % chance of being a bug.

 
 The message text says 'warning' but the compiler treats them as errors
 anyway.
 

 It generates some nasty spurious errors. For example, it 
 won't let you perform a bitwise operation on anything other than an int.

 short a;
 short b = a | a; // won't compile with -w !!!!


 
 Actually that turns out not to be the case. The 'warning/error' message in
 this situatation informs the coder that there is a potential loss of
 information when assigning a larger datatype to a smaller one. 
 
 "warning - test.d(4): Error: implicit conversion of expression
  (cast(int)a | cast (int)a) of type int to short can cause
  loss of data"
 
 The real problem with this is that D decides to convert your 'short' values
 to 'int' before doing the bitwise operation, leaving you with an 'int'
 value to squeeze back into a 'short'. Now you and I know that this is a
 redundant operation (converting to 'int') and that the high-end bits will
 be zeroes anyway so that there is no loss of information. But DMD is not
 that smart yet.
 
 The 'warning' message is a valid one, in the general sense. For example
 this code here gives a similar message ...


Not really. A usually incorrect error message is much, much worse than useless.
VC6 had one which was basically "warning: you're using templates". But at least 
you could selectively turn that off. Unfortunately with this one the only
option 
is to not use -w.

 
 void main(string[] args)
 {
   short argc = args.length;
 }
 
 Even though we all know that we are not going to have 2^32 command line
 arguments to the program. 
 
 The proper coding style to get the results you want is to tell the
 compiler, and other readers of your code, that you "know what you are doing
 so don't get upset"...



  short a;
  short b = cast(short)(a | a);
 
  short argc = cast(short)args.length;
 
 These do not give 'warning' messages now.


No, but now you've introduced a latent bug! If someone changes 'a' to be (say) 
int a, it will now be accepted even though in that case it DOES involve loss of 
data! Inserting a cast is not an acceptable workaround.
Would be better in the interim to not issue 'narrowing conversion' warnings at 
all, when they are so hopelessly incorrect.
Feb 23 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 24/02/2008, Don Clugston <dac nospam.com.au> wrote:

  Would be better in the interim to not issue 'narrowing conversion' warnings at
  all, when they are so hopelessly incorrect.


I think it would be better if widening type promotions were not done
where not necessary. That is, in general

    static assert(typeof(x op y) == CommonType!(typeof(x),typeof(y)));

That way, typeof(a | a) would be typeof(a), and if a was short, then
(a | a) would also be short.
Feb 24 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 24/02/2008, Janice Caron <caron800 googlemail.com> wrote:

 I think it would be better if widening type promotions were not done
  where not necessary.


"where not necessary" now becomes the problem. When is it necessary?

    ubyte n = 255;
    auto m = n + 2;

what type is m?

    uint x = 0xFFFFFFFF;
    auto y = x + 2;

what type is y?

These things obviously need clearly defined rules. Currently the rules
seem to be, if in doubt, use int. I don't know if that's necessarily
correct in all cases.
Feb 24 2008
parent Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

 On 24/02/2008, Janice Caron <caron800 googlemail.com> wrote:

 I think it would be better if widening type promotions were not done
  where not necessary.




Yes. But that's more work right now.

 
 "where not necessary" now becomes the problem. When is it necessary?
 
     ubyte n = 255;
     auto m = n + 2;
 
 what type is m?
 
     uint x = 0xFFFFFFFF;
     auto y = x + 2;
 
 what type is y?
 
 These things obviously need clearly defined rules. Currently the rules
 seem to be, if in doubt, use int. I don't know if that's necessarily
 correct in all cases.


I think this is all covered by polysemous types; Andrei in particular has given 
it considerable thought. As soon as they're introduced the problem should 
disappear for D2.

There's actually a fallacy in the page about warnings. They are not optional.
You can only use -w if the all of the libraries you are using support 
compilation with -w. Therefore, library developers are under considerable 
pressure to provide code which compiles with -w.
And therefore, library developers cannot use bitwise | & ^ operations on 
anything other than an int. ( |=, &=, ^= don't generate the warning, so they're
OK).
Feb 24 2008
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.47.1203635455.2351.digitalmars-d puremagic.com...
 

 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


 
 Except that it _does_ throw an exception to that effect in a debug build. 
 God, have you even _used_ D? 


Have you seen std.xml?

[I know you were being rhetorical -- but it's a good chance to mention 
this first public contribution (AFAIK) from Janice.]

--bb
Feb 21 2008
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Fri, 22 Feb 2008 09:06:17 +0900, Bill Baxter wrote:


 Jarrett Billingsley wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.47.1203635455.2351.digitalmars-d puremagic.com...
 

 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


 
 Except that it _does_ throw an exception to that effect in a debug build. 
 God, have you even _used_ D? 


 
 Have you seen std.xml?
 
 [I know you were being rhetorical -- but it's a good chance to mention 
 this first public contribution (AFAIK) from Janice.]


Which by the way is quite nice code and works well. (I was wondering how it
can be used to generate a DTD file from an XML document though.)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
22/02/2008 1:15:26 PM
Feb 21 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 22/02/2008, Derek Parnell <derek nomail.afraid.org> wrote:

  > Have you seen std.xml?

 Which by the way is quite nice code and works well. (I was wondering how it
  can be used to generate a DTD file from an XML document though.)


Right now, it can't. That's a "future direction" for it. Basically,
right now, it can't parse inside so-called "XML instructions" - those
weird things that you see in the prolog that start with "<!", like
<!DOCTYPE...> and <!ATTLIST...> and <!...ENTITY>. Currently, it treats
those things like opaque blobs and doesn't bother to look inside them.
DTDs (which are specified inside the <!DOCTYPE...> instruction) are a
whole level of complexity above and beyond XML itself - and not to
mention, now pretty much obsolete, having already been replaced by XML
Schema.

There are quite a few things I want to add to that module in time,
including (in no particular order) full support for XML namespaces,
DTDs and XML schemas (both full validation and creation thereof), XSL
style sheets, and so on. But I think the next thing I want to tackle
with regard to XML is the encoding. If a document starts "<?xml
version="1.0" encoding="ISO-8859-1"> then we're screwed, because D
only handles Unicode. Even reading in the document is hard! Tackling
that is next on the list, to be (shortly) followed by namespaces, and
probably the more tricky stuff some time after that.

But even without those things, it's a neat module to use. I was using
it before it went public, and the really nice thing about the parser
is that it makes use of closures. The handlers you give it can all use
anonymous delegates, declared inline, and they can refer to variable
in the enclosing scope, and that is something that I just find
/amazing/, and cheers to Walter for that! It's really that that makes
the parser such a joy to use, compared with, say, Expat. (Expat is
written in C, so obviously it can't have closures).

The module could really do with a proper tutorial, and maybe I'll
write one soon, but I'm hampered because all the auto-generated docs
have to come from ddoc comments and it's a bit limiting what you can
do with that (and sometimes it does the most bizarrely unexpected
things). I'd love to be able to put HTML into a ddoc ... Wait -
there's an idea for a feature request! Hmm... another thread coming
up!

Anyway, while we're venturing far into the realms of topic drift,
might I also mention that you should all look at where std.algorithm
is at now. That has really, really matured with D2.011 and it is now
absolutely fantastic. Thanks, Andrei.
Feb 21 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:



 I'd love to be able to put HTML into a ddoc ... Wait -
 there's an idea for a feature request! Hmm... another thread coming
 up!


I believe that has been asked for before and the answer from Walter was 
no, because he wants DDOC to be able to generate LaTeX or pdf or man 
pages or whatever format you desire just by changing the macros.

--bb
Feb 21 2008
parent "Janice Caron" <caron800 googlemail.com> writes:
On 22/02/2008, Bill Baxter <dnewsgroup billbaxter.com> wrote:

 Janice Caron wrote:


  > I'd love to be able to put HTML into a ddoc ... Wait -
  > there's an idea for a feature request! Hmm... another thread coming
  > up!


 I believe that has been asked for before and the answer from Walter was
  no, because he wants DDOC to be able to generate LaTeX or pdf or man
  pages or whatever format you desire just by changing the macros.


I actually did make another thread for that, in the end. You wanna
head there and tell me that again? I do have a good response! :-)
Feb 21 2008
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Jarrett Billingsley wrote:

 "Janice Caron" <caron800 googlemail.com> wrote in message 
 news:mailman.47.1203635455.2351.digitalmars-d puremagic.com...
 

 And while we're on the subject of random falling over, am I the only
 one who gets infuriated by the occasional "Win32 Exception" halting a
 program with no further explanation? They happen when the flow of
 execution hits the bottom of a function without returning, when it's
 supposed to return something. I'm surprised we can't catch those at
 compile time, but even a nice D Exception throw at runtime (...again,
 in a debug build only...) would be useful.


 
 Except that it _does_ throw an exception to that effect in a debug build. 
 God, have you even _used_ D? 


Only on windows.  On any posix/unix platform it doesn't.  Throwing 
exceptions for these sorts of faults is dubious, imho, but windows has 
made it seem normal.

Later,
Brad
Feb 21 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron wrote:

 Of course, what I'd /really/ prefer is a runtime check (in debug
 builds only, of course) for all null dereferences. I see it as
 basically the same as array bounds checking - for speed, you don't
 want it in a final release, but during development, you sacrifice the
 speed and let the compiler help out. That would be useful, because not
 only would it catch ==null, but it would also catch .member and
 .func(), and you'd get a nice error message telling what line of what
 file threw the exception.


Emphatic "me too".
Feb 21 2008