Ivan Senji wrote:
> xs0 wrote:
>> Would you care for any language that (regardless of other features) made you type "return a+b" like this:
>>
>> accumulator foo;
>> foo.add(a);
>> foo.add(b);
>> return foo.result;
>>
>> Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus
> 
> Actually this works. But foo cannot be initialized with an initializer.

OK, that particular statement might work, but it doesn't do what you expect:

int[][][] foo = new int[3][4][5];

results in

arr.d(4): cannot implicitly convert expression (new int[3][4][](5)) of type int[3][4][] to int[][][]

and more importantly, this doesn't work:

int a=3, b=4, c=5;
auto foo = new int[a][b][c];

produces

arr.d(5): Integer constant expression expected instead of a
arr.d(5): Integer constant expression expected instead of a
arr.d(5): Integer constant expression expected instead of b
arr.d(5): Integer constant expression expected instead of b


xs0

xs0 wrote:
> Ivan Senji wrote:
>> xs0 wrote:
>>> Would you care for any language that (regardless of other features) made you type "return a+b" like this:
>>>
>>> accumulator foo;
>>> foo.add(a);
>>> foo.add(b);
>>> return foo.result;
>>>
>>> Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus
>>
>> Actually this works. But foo cannot be initialized with an initializer.
> 
> OK, that particular statement might work, but it doesn't do what you expect:
> 
> int[][][] foo = new int[3][4][5];
> 
> results in
> 
> arr.d(4): cannot implicitly convert expression (new int[3][4][](5)) of type int[3][4][] to int[][][]
> 
> and more importantly, this doesn't work:
> 
> int a=3, b=4, c=5;
> auto foo = new int[a][b][c];

Oops, now I remember that it doesn't work. I got my hopes up to soon :)

Walter Bright wrote:
> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.

Maybe not the right time to mention it but: one of the most annoying error messages dmd produces is "is not an lvalue". An annoying message isn't doesn't make a good first impression, and it makes an even worse second or third impression.

Example:

  class A
  {
    int xx = 11;
    int opIndex(int pos){return xx;}
    int opIndexAssign(int what, int pos){return xx = what;}

    int prop(){return xx;}
    int prop(int newxx){return xx = newxx;}
  }

  auto a = new A;

  void f(inout int x)
  {
    x ++;
  }

  f(a[5]);    //((a).opIndex)(5) is not an lvalue
  f(a.prop);  //((a).prop)() is not an lvalue

Maybe a[5] isn't strictly an lvalue because it's adress can't be taken but, it would make much sense for the compiler to translate those cases to (and shouldn't be that hard to do):

auto x = a[5];
  f(x);
a[5] = x;

auto y = a.prop;
  f(y);
a.prop = y;

I don't want to sound lika a D-hater because of my recent (complaining) posts but just trying to show that although D is a fantastic language it is still a little too rough around the edges.

On Mon, 04 Sep 2006 14:32:54 +0300, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:

> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
>
> Maybe not the right time to mention it but: one of the most annoying error messages dmd produces is "is not an lvalue". An annoying message isn't doesn't make a good first impression, and it makes an even worse second or third impression.
>
> Example:
>
>    class A
>    {
>      int xx = 11;
>      int opIndex(int pos){return xx;}
>      int opIndexAssign(int what, int pos){return xx = what;}
>
>      int prop(){return xx;}
>      int prop(int newxx){return xx = newxx;}
>    }
>
>    auto a = new A;
>
>    void f(inout int x)
>    {
>      x ++;
>    }
>
>    f(a[5]);    //((a).opIndex)(5) is not an lvalue
>    f(a.prop);  //((a).prop)() is not an lvalue
>
> Maybe a[5] isn't strictly an lvalue because it's adress can't be taken but, it would make much sense for the compiler to translate those cases to (and shouldn't be that hard to do):
>
> auto x = a[5];
>    f(x);
> a[5] = x;
>
> auto y = a.prop;
>    f(y);
> a.prop = y;
>
> I don't want to sound lika a D-hater because of my recent (complaining) posts but just trying to show that although D is a fantastic language it is still a little too rough around the edges.

Special, cool features are fine when making a good first expression. But basic stuff is the most important part of a language, IMHO. That's because you do basic stuff a lot. If something annoys you a little constantly, it'll annoy you a lot after a while.

(This is too harsh of an example, but if a cake looks delicious you may buy it, but if it doesn't taste good, you won't buy it again.)

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
>>
>> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
> 
> It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.

I'm a bit at a loss.
A given version can mean:
"usable" - good enough to be used for actual work.
"completed/finished" - all major known problems and changes have been resolved, as well as most of the minor ones. (it doesn't mean the program is final, there can be *new* additions of course.)

So, you're not asking what D needs in order to be considered "completed/finished", but rather if D is "usable"? You're asking if D (.166) is usable?
Or rather, are you asking if the "1.0" label should be used to mean that, rather than to mean "completed/finished"?


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

Don Clugston wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
>>> Walter Bright wrote:
>>>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
> 
> Provided that the future plans for new syntax don't involve breaking lots of existing code, then I would say yes. I'm not yet convinced that this is true for the future RAII syntax (but I'm not convinced that it isn't true, either).

Good point.  Personally, I'd like to get the new syntax now, even if stack allocation doesn't occur until later.  I think this means potentially dropping 'auto' from class declarations (so "auto class C {}" would be illegal) and making duplicate storage classes illegal for declarations (so "auto auto x = new MyClass()" would be illegal).  Also:

    MyClass c = MyClass();

could convert to:

    MyClass c = new MyClass();
    scope(exit) delete c;

and:

    char[] b = char[32];

could convert to:

    char[] b = new char[32];
    scope(exit) delete b;

With the appropriate extensions for type inference as well. Alternately, alloca could be used for the allocations if that's possible.


Sean

Ivan Senji wrote:
> I didn't just switch to D and start complaining that this and that
> is missing, my complaints (and of other long time users) comes from actually *using* D.

And so your suggestions are valuable, but I was responding to the post about first impressions from some Java users.

Ivan Senji wrote:
> Maybe not the right time to mention it but: one of the most annoying error messages dmd produces is "is not an lvalue". An annoying message isn't doesn't make a good first impression, and it makes an even worse second or third impression.
> 
> Example:
> 
>   class A
>   {
>     int xx = 11;
>     int opIndex(int pos){return xx;}
>     int opIndexAssign(int what, int pos){return xx = what;}
> 
>     int prop(){return xx;}
>     int prop(int newxx){return xx = newxx;}
>   }
> 
>   auto a = new A;
> 
>   void f(inout int x)
>   {
>     x ++;
>   }
> 
>   f(a[5]);    //((a).opIndex)(5) is not an lvalue
>   f(a.prop);  //((a).prop)() is not an lvalue
> 
> Maybe a[5] isn't strictly an lvalue because it's adress can't be taken but, it would make much sense for the compiler to translate those cases to (and shouldn't be that hard to do):
> 
> auto x = a[5];
>   f(x);
> a[5] = x;
> 
> auto y = a.prop;
>   f(y);
> a.prop = y;
> 
> I don't want to sound lika a D-hater because of my recent (complaining) posts but just trying to show that although D is a fantastic language it is still a little too rough around the edges.

The compiler can translate those cases, but I feel that would be the wrong thing to do. If a function has inout for a parameter, it means that the function is expected to essentially return a value through the parameter. If the user calls a function with a parameter that cannot accept such a return value, it is most likely a mistake. If the compiler rewrites the code so it "works", then it's probably going to make finding the bug difficult.

It's an error in C++ for the same reason (can't initialize a reference with a non-const).

xs0 wrote:
> Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.

You clearly know the particular circumstances better than I.

An interesting question is: why are they using Java, and why strictly?

Walter Bright wrote:

> xs0 wrote:
>> Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.
> 
> You clearly know the particular circumstances better than I.
> 
> An interesting question is: why are they using Java, and why strictly?

This generally happens when languages (like Java and C# especially, but I guess also C++) get so large abundances of frameworks and libraries to work with, that investing time in other technologies either becomes counterproductive or just not feasible (or even necessary). Even if the Java solutions might not be perfect, you can get very far quickly by utilizing what's already there.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi