digitalmars.D - Suggestion: Remove implicit conversion from T[n] and T[] to T*
- Oskar Linde (41/41) Nov 30 2006 Removing the implicit conversion from static arrays (T[n]) and dynamic
- Jarrett Billingsley (4/16) Nov 30 2006 I suggested this as well a while ago for much the same reasons, and I st...
- Derek Parnell (5/7) Nov 30 2006 It does, doesn't it. A good idea. The pretence that D is C/C++ on sterio...
- Kyle Furlong (2/56) Nov 30 2006 /agree
- Lars Ivar Igesund (6/60) Nov 30 2006 Aye. o/
- Andrey Khropov (4/8) Nov 30 2006 Yep, you have my vote.
- Tom (4/58) Nov 30 2006 Another vote.
- Don Clugston (9/22) Nov 30 2006 I fully support this.
- Johan Granberg (2/56) Dec 01 2006 Sounds like a good idea.
- Bruno Medeiros (5/59) Dec 01 2006 Very yes!
- Alexander Panek (9/63) Dec 01 2006 I may be now slaughtered, but actually the implicit conversion isn't
- akcom (4/45) Dec 01 2006 I was completely unaware that this is done implicitly, I've always used ...
- Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= (2/6) Dec 01 2006 +1
- renoX (3/6) Dec 01 2006 +1 especially since it's easy to add the .ptr when you need the conversi...
- Tomas Lindquist Olsen (3/3) Dec 02 2006 I think it should stay as-is for the sole reason that otherwise this
- Oskar Linde (8/11) Dec 02 2006 String literals in D are special in the way that the type they commit to...
- Alexander Panek (2/16) Dec 02 2006
- Jarrett Billingsley (16/19) Dec 02 2006 Waitwaitwait.. surely you mean:
- Carlos Santander (4/8) Dec 02 2006 I vote for this too.
- Witold Baryluk (3/7) Dec 03 2006 I agree. It's more elegant and safer to write such thing explicit.
- Walter Bright (2/5) Dec 03 2006 Looks like that implicit cast is going down in flames!
- Bill Baxter (7/13) Dec 04 2006 Suggestion: could you make it a compiler flag for the next release so we...
- Walter Bright (3/16) Dec 04 2006 That's a good idea, but I suggest reversing it. Make the change, with a
- Jarrett Billingsley (3/4) Dec 04 2006 Wooooo!
- Lionello Lunesu (4/4) Dec 04 2006 Good one..
- Walter Bright (3/6) Dec 04 2006 Likely true, but 150 changes just in Phobos are a lot of changes. Do you...
- Tom S (3/10) Dec 04 2006 Well, better now than after thousands of complaints from millions of new...
- Thomas Kuehne (2/8) Dec 04 2006 Yes
- Pragma (15/22) Dec 04 2006 Well to take the devil's advocate, the only reasons I can think to keep
- Sean Kelly (10/13) Dec 04 2006 Would this affect the interpretation of string literals? ie.
- Walter Bright (3/11) Dec 04 2006 No. String literal implicit conversions can happen independently of
- Sean Kelly (6/18) Dec 04 2006 Then I think it's a good idea. It improves code readability and reduces...
Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /Oskar
Nov 30 2006
"Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message news:ekn8dq$f5t$1 digitaldaemon.com...Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power.I suggested this as well a while ago for much the same reasons, and I still support it.
Nov 30 2006
On Thu, 30 Nov 2006 19:37:46 +0100, Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* ... feels like the right step to take.It does, doesn't it. A good idea. The pretence that D is C/C++ on steriods is wrong. D is no longer a dialect of C/C++. -- Derek Parnell
Nov 30 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /Oskar/agree
Nov 30 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /OskarAye. o/ -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Nov 30 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Yep, you have my vote. -- AKhropov
Nov 30 2006
Another vote. -- Tom; Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /Oskar
Nov 30 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power.I fully support this. implicit conversion from char [] to char *. When passing a char [] to a C function, it's so easy to forget to add the null terminator. I've found this hard to track down, especially because of DMD's habit of adding a null to the end of char[] arrays; it means your code seems to work fine, until you use an array slice instead of an array...
Nov 30 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /OskarSounds like a good idea.
Dec 01 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /OskarVery yes! -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 01 2006
I may be now slaughtered, but actually the implicit conversion isn't such a bad thing. Given the fact, that T[] is just a struct of a pointer and a length, the reference implicitely points to the same address as T[].ptr anyways, it's pretty much obvious to have a reason for implicit conversion. But that's just me, and if it's really causing bugs (..I couldn't think of any, though), why not? Kind regards, Alex Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /Oskar
Dec 01 2006
I was completely unaware that this is done implicitly, I've always used the ptr property. This has my vote as well. "Oskar Linde" <oskar.lindeREM OVEgmail.com> wrote in message news:ekn8dq$f5t$1 digitaldaemon.com...Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take. Motivation: - Implicit conversions are generally bad. There are cases where they make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by using that the code is clearer and more self documenting. - T[] contains both a length and a ptr. Both are needed to retain the information. Symmetrically requiring (a.ptr, a.length) makes sense. - Decoupling arrays from pointers somewhat lifts D to a slightly higher abstraction level without losing any power. Case study: Phobos Phobos contains 150 lines that rely on implicit T[n] and T[] => T* conversions. (Not counting multi-typed string literals that magically bypass the regular conversion rules.) Of those 78 lines (52 %) are directly related to calls to C functions. Including: 21 s[n]printf 20 memcmp 17 memcpy Requiring changes such as: - .send(sock, buf, buf.length, cast(int)flags); + .send(sock, buf.ptr, buf.length, cast(int)flags); 16 are C-like D function calls, like - writeBlock(bom,bom.length); + writeBlock(bom.ptr, bom.length); 29 are trivial assignments, like: - ubyte *str = s; + ubyte *str = s.ptr; 7 are "new", where this change has a slight negative impact on code: - R = new dchar[Rsize]; + R = (new dchar[Rsize]).ptr; 20 remaining are other minor changes like: - if (sp != stack) + if (sp != stack.ptr) I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity. Comments? /Oskar
Dec 01 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Comments?+1
Dec 01 2006
Oskar Linde a écrit :Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.+1 especially since it's easy to add the .ptr when you need the conversion. renoX
Dec 01 2006
I think it should stay as-is for the sole reason that otherwise this wouldn't work: printf("hello world");
Dec 02 2006
== Quote from Tomas Lindquist Olsen (tomas famolsen.dk)'s articleI think it should stay as-is for the sole reason that otherwise this wouldn't work: printf("hello world");String literals in D are special in the way that the type they commit to are dependent on the context they appear in. That means that the above could still work even if the implicit conversion was removed. This is the reason I didn't count those occurrences in the Phobos analysis. String literals (and maybe const-folded string expressions?) are the only cases where D guarantees zero termination. /Oskar
Dec 02 2006
Apart from that is printf obsolete. :P Oskar Linde wrote:== Quote from Tomas Lindquist Olsen (tomas famolsen.dk)'s articleI think it should stay as-is for the sole reason that otherwise this wouldn't work: printf("hello world");String literals in D are special in the way that the type they commit to are dependent on the context they appear in. That means that the above could still work even if the implicit conversion was removed. This is the reason I didn't count those occurrences in the Phobos analysis. String literals (and maybe const-folded string expressions?) are the only cases where D guarantees zero termination. /Oskar
Dec 02 2006
"Tomas Lindquist Olsen" <tomas famolsen.dk> wrote in message news:ekrhqi$7c0$1 digitaldaemon.com...I think it should stay as-is for the sole reason that otherwise this wouldn't work: printf("hello world");Waitwaitwait.. surely you mean: writefln("hello world"); ? ;) See, I think the implicit conversion from char[] to char* exists only for this purpose -- for Walter to be able to write printf statements with string literals. But the problem gets much worse when you're not using string literals -- i.e. you get access violations. That, and does anyone know if it says _anywhere_ in the D spec that string literals are _required_ to be zero-terminated? What if that "feature" (again, useful only for passing to C string handling functions) goes away, or if another compiler doesn't do it? D's arrays (and its strings in particular) are not the same as C's. Trying to make the conversion from D's to C's implicit only leads to confusion and bugs.
Dec 02 2006
Oskar Linde escribió:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.I vote for this too. -- Carlos Santander Bernal
Dec 02 2006
Dnia Thu, 30 Nov 2006 19:37:46 +0100 Oskar Linde <oskar.lindeREM OVEgmail.com> napisa=B3/a:- Implicit conversions are generally bad. There are cases where they=20 make sense, but those need a very good reason. - Both conversions are available by the .ptr property already and by=20 using that the code is clearer and more self documenting.I agree. It's more elegant and safer to write such thing explicit.
Dec 03 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Looks like that implicit cast is going down in flames!
Dec 03 2006
Walter Bright wrote:Oskar Linde wrote:Suggestion: could you make it a compiler flag for the next release so we can try it out on our own code? I for one have no idea how much pain the change will cause me. I'm vaguely for it, since .ptr isn't that much to type, and generally I prefer explicit to implicit, but that's only if the pain involved is not too great. --bbRemoving the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Looks like that implicit cast is going down in flames!
Dec 04 2006
Bill Baxter wrote:Walter Bright wrote:That's a good idea, but I suggest reversing it. Make the change, with a switch to revert it back. That way, you won't have to change your makefiles.Oskar Linde wrote:Suggestion: could you make it a compiler flag for the next release so we can try it out on our own code? I for one have no idea how much pain the change will cause me. I'm vaguely for it, since .ptr isn't that much to type, and generally I prefer explicit to implicit, but that's only if the pain involved is not too great.Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Looks like that implicit cast is going down in flames!
Dec 04 2006
"Walter Bright" <newshound digitalmars.com> wrote in message news:el0kfq$319u$2 digitaldaemon.com...Looks like that implicit cast is going down in flames!Wooooo!
Dec 04 2006
Good one.. And in the future, .ptr might also support pinning. Imagine pinning being done implicitly :) L.
Dec 04 2006
Oskar Linde wrote:I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity.Likely true, but 150 changes just in Phobos are a lot of changes. Do you guys really want to do this?
Dec 04 2006
Walter Bright wrote:Oskar Linde wrote:Well, better now than after thousands of complaints from millions of new users ;)I am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity.Likely true, but 150 changes just in Phobos are a lot of changes. Do you guys really want to do this?
Dec 04 2006
Walter Bright schrieb am 2006-12-04:Oskar Linde wrote:YesI am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity.Likely true, but 150 changes just in Phobos are a lot of changes. Do you guys really want to do this?
Dec 04 2006
Walter Bright wrote:Oskar Linde wrote:Well to take the devil's advocate, the only reasons I can think to keep this kind of implicit cast are: - it's mildly familiar to C programmers, thanks to how C arrays are handled. - It could help with porting C code into D. And... that's it. That's the strongest argument I can muster. In my mind, there's really no other reasons not to do this. The argument that Oskar puts forward at the start of this thread is well put and quite valid (IMO). Don also brought up a good point that it'll *reduce* errors when interfacing with C code (of all things). Finally, I cannot recall another thread on this newsgroup that had such an overwhelmingly one-sided vote from active posters. I think we should really do this. -- - EricAnderton at yahooI am very likely to have made some mistakes in this analysis, and missed important cases, but in general, I think most of the changes actually increase the code clarity.Likely true, but 150 changes just in Phobos are a lot of changes. Do you guys really want to do this?
Dec 04 2006
Oskar Linde wrote:Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Would this affect the interpretation of string literals? ie. printf( "hello world!" ); I've personally never had a bug related to this aspect of the language so for me it's simply a matter of whether the perceived benefits outweigh the irritation of using the new syntax. One possible alternative to the above would be to simply change all char* parameters for C routines to byte* parameters. Or are char arrays implicitly converted to byte pointers as well? Sean
Dec 04 2006
Sean Kelly wrote:Oskar Linde wrote:No. String literal implicit conversions can happen independently of implicit type conversions.Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Would this affect the interpretation of string literals? ie. printf( "hello world!" );
Dec 04 2006
Walter Bright wrote:Sean Kelly wrote:Then I think it's a good idea. It improves code readability and reduces the risk of bugs. I'm quite used to doing this with vectors in C++ anyway (via the "address of first element" syntax) and like that the conversion there must be explicit. SeanOskar Linde wrote:No. String literal implicit conversions can happen independently of implicit type conversions.Removing the implicit conversion from static arrays (T[n]) and dynamic arrays (T[]) to pointers T* may be quite controversial, but would help clear up some problems and feels like the right step to take.Would this affect the interpretation of string literals? ie. printf( "hello world!" );
Dec 04 2006