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

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


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.


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 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 :-)


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 :-)


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 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 :-)


"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.


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 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 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 next sibling parent "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
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 next 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 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
prev sibling next 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 Mkel 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 parent 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 :-)


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
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

C# does exactly the same as MiniD. I don't recall how that works with 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 next 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
next sibling 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;


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
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 next 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
next sibling 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
next sibling 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,


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

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 next 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
prev sibling next 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 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.

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.

-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
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 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
prev 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 "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 next sibling parent "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
prev sibling parent "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
prev 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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent "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,


 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
prev sibling next 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 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 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
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 "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