Walter Bright wrote:
> Lucas Goss wrote:
>> Is there any benefit to having a separate symbol for adding (ok, concatenating)? If not feel free to break the language here too.
> 
> Concatenation is quite different from addition:
> 
> int[3] a = [1,2,3];
> int[3] b = [4,5,6];
> 
> int[] c = a + b;    // c[] = [5,7,9]
> int[] d = a ~ b;    // d[] = [1,2,3,4,5,6]
> 
> Two distinct operators are necessary.

Ah, thanks! That makes sense.

Lucas

Derek Parnell wrote:
> On Sat, 01 Jul 2006 05:47:51 +1000, Deewiant <deewiant.doesnotlike.spam@gmail.com> wrote:
> 
>> Deewiant wrote:
> 
>>
>> I found the post in question, BTW. Here's the Google Groups link:
>> In summary:
>>
>> Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
>> good reason - C compatibility."
>>
>> Walter responds: "I should have. Too much water under the bridge for that now."
>>
>> In the same post Walter also acknowledges that "There has been some talk in the
>> D newsgroups of doing that, but it has the potential to be extremely disruptive."
> 
> This would be a welcomed disruption as it makes D a much better product. I have no problems about retrofitting this sort of change in all my D code.
> 

I agree.

People can always use the current version if they need to support code that this breaks.

> --Derek Parnell
> Melbourne, Australia

Chris Nicholson-Sauls wrote:
> Except for "Array operations not implemented" as yet.  Any idea when this much-coveted, much-anticipated feature will come to life?  I don't mean to push, but I've dreamt of array-ops nearly since I first got involved with D back in 2003.

It'll have to be a 2.0 thing.

Deewiant wrote:
> Deewiant wrote:
>> Sean Kelly wrote:
>>> I've become convinced that the "default everything to const" method seems ideal, but this seems like something that should really be done before 1.0 if it's going to happen?
>>>
>>> Sean
>> I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was there) that he thinks he should have made D like this from the start, but that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
>>  too late to break even every single line of D code out there.
> 
> I found the post in question, BTW. Here's the Google Groups link:
> 
> http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
> 
> In summary:
> 
> Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
> good reason - C compatibility."
> 
> Walter responds: "I should have. Too much water under the bridge for that now."
> 
> In the same post Walter also acknowledges that "There has been some talk in the
> D newsgroups of doing that, but it has the potential to be extremely disruptive."

Good thread, I highly agree with what Andrei said in that segment. In summary, that a language supported read-only view of data is significantly beneficial.

As for the backwards compatibility issue, I've said it before: D, as a language in development, should not be blocked by backwards compatibility issues in detriment of beneficial changes. Of course, such changes must be extensively thought about and discussed beforehand.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Deewiant wrote:
> 
> I found the post in question, BTW. Here's the Google Groups link:
> 
> http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
> 
> In summary:
> 
> Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
> good reason - C compatibility."
> 
> Walter responds: "I should have. Too much water under the bridge for that now."
> 
> In the same post Walter also acknowledges that "There has been some talk in the
> D newsgroups of doing that, but it has the potential to be extremely disruptive."

Subj.

ps. Sorry for flood, but i just can't help it =)
--
serg.

Walter Bright skrev:
> Chris Nicholson-Sauls wrote:
> 
>> Except for "Array operations not implemented" as yet.  Any idea when this much-coveted, much-anticipated feature will come to life?  I don't mean to push, but I've dreamt of array-ops nearly since I first got involved with D back in 2003.
> 
> 
> It'll have to be a 2.0 thing.
Perhaps not part of core language, put thought operator overloads. I guess there are a million reasons as to why not have them, but if I could choose this would be a nice syntax for both introducing operator overloads and properties to existing types:

type int[] {

    int[] opAdd(int[] a) {
        assert(this.length == a.length);
        int[] r; r.length = this.length;
        foreach (i, v; this) {
            r[i] = v + a[i];
        }
        return r;
    }

    int sum() {
        int r = 0;
        foreach(v; this) {
            r += v;
        }
        return v;
    }

}

// Making these work;
int[] a = [1, 2, 3];
int[] b = [4, 5, 6];
int[] c = a + b; // [5, 7, 9];
int d = c.sum(); // 15


// Fredrik

Fredrik Olsson wrote:
> Walter Bright skrev:
> 
>> Chris Nicholson-Sauls wrote:
>>
>>> Except for "Array operations not implemented" as yet.  Any idea when this much-coveted, much-anticipated feature will come to life?  I don't mean to push, but I've dreamt of array-ops nearly since I first got involved with D back in 2003.
>>
>>
>>
>> It'll have to be a 2.0 thing.
> 
> Perhaps not part of core language, put thought operator overloads. I guess there are a million reasons as to why not have them, but if I could choose this would be a nice syntax for both introducing operator overloads and properties to existing types:
> 
> type int[] {
> 
>     int[] opAdd(int[] a) {
>         assert(this.length == a.length);
>         int[] r; r.length = this.length;
>         foreach (i, v; this) {
>             r[i] = v + a[i];
>         }
>         return r;
>     }
> 
>     int sum() {
>         int r = 0;
>         foreach(v; this) {
>             r += v;
>         }
>         return v;
>     }
> 
> }
> 
> // Making these work;
> int[] a = [1, 2, 3];
> int[] b = [4, 5, 6];
> int[] c = a + b; // [5, 7, 9];
> int d = c.sum(); // 15
> 
> 
> // Fredrik

This gives me a thought.  Currently we have the pseudo-member effect, which causes the following to be possible:

# int sum (int[] arr) {
#   int result = 0 ;
#
#   foreach (i; arr)
#     result += arr;
#
#   return result;
# }
#
# int[] foo = [1, 2, 3, 4] ;
# int   bar = foo.sum      ; // bar == 1 + 2 + 3 + 4 == 10

Also, in D (theoretically at least) it seems all operators are rewritten as function calls.  Such that the expression (a + b) becomes (a.opAdd(b)).  So, perhaps we could do something like this:

# int[] opAdd (int[] a, int[] b)
# in {
#   assert( a.length == b.length, "Array-Ops only applicable to arrays of equal length" );
# }
# body {
#   int[] result = new int[a.length] ;
#
#   foreach (i, x; a) {
#     result[i] = x + b[i];
#   }
#   return result.dup;
# }
#
# int[] foo = [1, 2, 3] ,
#       bar = [4, 5, 6] ;
#
# int[] xyz = foo + bar ; // (foo.opAdd(bar)) -> (.opAdd(foo, bar)) == [5, 7, 9]

Just a crazy thought.

-- Chris Nicholson-Sauls