www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Suggestion: Remove implicit conversion from T[n] and T[] to T*

reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
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
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
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
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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


Aye. o/

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Nov 30 2006
prev sibling next sibling parent "Andrey Khropov" <andkhropov_nosp m_mtu-net.ru> writes:
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
prev sibling next sibling parent Tom <tom nospam.com> writes:
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
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
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
prev sibling next sibling parent Johan Granberg <lijat.meREM OVE.gmail.com> writes:
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


Sounds like a good idea.
Dec 01 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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


Very yes!

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 01 2006
prev sibling next sibling parent Alexander Panek <a.panek brainsware.org> writes:
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
prev sibling next sibling parent "akcom" <CppCoder gmail.com> writes:
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
prev sibling next sibling parent Dawid =?UTF-8?B?Q2nEmcW8YXJraWV3aWN6?= <dawid.ciezarkiewicz gmail.com> writes:
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
prev sibling next sibling parent renoX <renosky free.fr> writes:
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
prev sibling next sibling parent reply "Tomas Lindquist Olsen" <tomas famolsen.dk> writes:
I think it should stay as-is for the sole reason that otherwise this
wouldn't work:

printf("hello world");
Dec 02 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
== Quote from Tomas Lindquist Olsen (tomas famolsen.dk)'s article

 I 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
parent Alexander Panek <a.panek brainsware.org> writes:
Apart from that is printf obsolete. :P

Oskar Linde wrote:

 == Quote from Tomas Lindquist Olsen (tomas famolsen.dk)'s article

 I 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
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
prev sibling next sibling parent Carlos Santander <csantander619 gmail.com> writes:
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
prev sibling next sibling parent Witold Baryluk <baryluk mpi.int.pl> writes:
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
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 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!


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.

--bb
Dec 04 2006
parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 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!


 
 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.


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.
Dec 04 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Good one..

And in the future, .ptr might also support pinning. Imagine pinning 
being done implicitly :)

L.
Dec 04 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 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?


Well, better now than after thousands of complaints from millions of new 
users ;)
Dec 04 2006
prev sibling next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
Walter Bright schrieb am 2006-12-04:

 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?


Yes
Dec 04 2006
prev sibling parent Pragma <ericanderton yahoo.removeme.com> writes:
Walter Bright wrote:

 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?


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 yahoo
Dec 04 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 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!" );


No. String literal implicit conversions can happen independently of 
implicit type conversions.
Dec 04 2006
parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Sean Kelly wrote:

 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!" );


 
 No. String literal implicit conversions can happen independently of 
 implicit type conversions.


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.


Sean
Dec 04 2006