www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Is DMD 0.166 RC 1.0?

reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 02 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
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.


Are you talking about DMD or D?

I think that all *D* needs is some editing of the spec (disambiguating, 
typo corrections, etc.) A feature freeze NOW wouldn't bug me a bit.

DMD on the other hand has a ways to go. I've got a few pet peeves* and 
there is a bunch of known issues under dstress and the issue list.

Lastly after D is declared 1.0 RCn, DMD should be confirmed to actually 
(for the most part) implement it correctly before it is declared 1.0. 
For that I'm thinking of a systematic sweep of the spec where test cases 
are generated for as many parts as can be managed. Each test case should 
be confirmed to work or be tagged as a correct program (a.k.a a known 
issue).

Submitting these to dstress might be a good idea also.

*> http://d.puremagic.com/issues/show_bug.cgi?id=52
Sep 02 2006
parent Juan Jose Comellas <jcomellas gmail.com> writes:
BCS 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.


 
 Are you talking about DMD or D?
 
 I think that all *D* needs is some editing of the spec (disambiguating,
 typo corrections, etc.) A feature freeze NOW wouldn't bug me a bit.
 
 DMD on the other hand has a ways to go. I've got a few pet peeves* and
 there is a bunch of known issues under dstress and the issue list.
 
 Lastly after D is declared 1.0 RCn, DMD should be confirmed to actually
 (for the most part) implement it correctly before it is declared 1.0.
 For that I'm thinking of a systematic sweep of the spec where test cases
 are generated for as many parts as can be managed. Each test case should
 be confirmed to work or be tagged as a correct program (a.k.a a known
 issue).
 
 Submitting these to dstress might be a good idea also.
 
 *> http://d.puremagic.com/issues/show_bug.cgi?id=52


I think this is an important distinction to make. The D spec may be ready 
and DMD might be ready on Windows too, but the Linux version is far from
being usable for any kind of production environment. Once DMD on Linux
generates correct debug information, allows the creation of shared
libraries and has no code generation problems (see
http://d.puremagic.com/issues/show_bug.cgi?id=315) we could probably talk
about it.

Is the Linux DMD version intended to be part of the 1.0 release?
Sep 03 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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.


Please stop teasing us with these silly questions.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 02 2006
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
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.


Um, it ought to.

I think you ought to branch.  Branch off 1.0 with a feature freeze, and 
also an "experimental" new-features new-stuff branch.  Rather than 
rejecting all new features, put them in the experimental branch.  That 
branch then later becomes 1.1 or 2.0 (depending on how you choose to 
number, etc).  That way, people who just want a stable software platform 
can choose 1.0, and those who live on the bleeding edge can choose the 
experimental branch.

  - Gregor Richards
Sep 02 2006
next sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Gregor Richards 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.


 
 Um, it ought to.
 
 I think you ought to branch.  Branch off 1.0 with a feature freeze, and 
 also an "experimental" new-features new-stuff branch.  Rather than 
 rejecting all new features, put them in the experimental branch.  That 
 branch then later becomes 1.1 or 2.0 (depending on how you choose to 
 number, etc).  That way, people who just want a stable software platform 
 can choose 1.0, and those who live on the bleeding edge can choose the 
 experimental branch.
 
  - Gregor Richards


Make 1.1 the experimental branch, and save 1.2 for the next 
release branch.  The same even/odd thing that the Linux kernel 
used to use.  It worked well there, arguably better than the 
current approach.  But think about the release numerations. 
If it's a string, then use 1.1.001 for the first experimental 
version.  If it's a float, think about switching to a string. 
  An alternate choice would be to consider it a struct with 
three fields (ubyte?) called: version, branch, and subversion.
Sep 02 2006
prev sibling parent Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Gregor Richards 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.


 
 Um, it ought to.
 
 I think you ought to branch.  Branch off 1.0 with a feature freeze, and 
 also an "experimental" new-features new-stuff branch.  Rather than 
 rejecting all new features, put them in the experimental branch.  That 
 branch then later becomes 1.1 or 2.0 (depending on how you choose to 
 number, etc).  That way, people who just want a stable software platform 
 can choose 1.0, and those who live on the bleeding edge can choose the 
 experimental branch.
 
  - Gregor Richards


I agree. We don't want to stop getting new features just so that *other* 
people can have the "stable" version they've always wanted.

I think there's nothing outstandingly wrong with DMD 0.166 that prevents 
it being RC 1.0.

Cheers,

Reiner
Sep 03 2006
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
I agree with Gregor Richards about branching if you are chomping at the bit 
to add some hot new features.

However, IMO, the biggest problem I see with DMD in its current state is 
that IFTI is not finished yet.  Since IFTI will have such a large impact on 
library development, I think completing it should be high on the priority 
list.

-Craig
Sep 02 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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.


Why not: IFTI needs polish, array literals are just too valuable (although IFTI
helps here 
too), Phobos needs a std.array (templatized!), need to resolve current
enhancement/feature 
requests and suggestions -- aka, any new requests from "This Point" forward are
tagged for 
the next release, but anything currently on the table needs to get resolved to
one of "not 
going to happen", "will happen and here's how", or "deferred to next release
because it 
just can't be done and here's why".

-- Chris Nicholson-Sauls
Sep 02 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 03 2006
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
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?


I'm beginning to think it's just Walter's impatience showing.  He wants 
to get 1.0 out sooner rather than later, so he keeps pushing us to let 
it happen.  But it isn't going to happen.  1.0 time will come when it's 
ready.  When both general and specific criteria are fulfilled.  See also 
digitalmars.D.bugs:8272, "d1.0blocker - anyone at home?"

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.
Sep 03 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 03 2006
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:

 Bruno Medeiros wrote:


<snip>

 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.


Then make some effort to debunk these impressions.  Don't try to work 
around them.

Moreover, just think about what will happen when people see 1.0 and 
expect to see a well-defined language specification, and maybe even to 
be ready to write a D compiler themselves.  When they find themselves 
disappointed, just how bad will the negative image be, and how much work 
will it take to get rid of it?  Moreover, how will compiler writers, and 
software houses wanting to adopt D, know when it's OK to come back?

Yet another criterion to consider is that the language lives up to its 
claims.  One of your claims is to make it likely that multiple, correct 
implementations will be available.  This is impossible as long as the 
spec still has a number of ill-defined bits.

OTOH, how many people have you counted who have dismissed D just because 
it isn't at 1.0?  Did any of these people tell you that they would come 
back at 1.0 no matter what condition 1.0 is in?  I'd be surprised.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-  C++  a->--- UB  P+ L E  W++  N+++ o K-  w++  O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Sep 03 2006
parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:

 Walter Bright wrote:

 Bruno Medeiros wrote:


 <snip>

 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.


 
 Then make some effort to debunk these impressions.  Don't try to work 
 around them.


I learned long ago that it is far easier to swim with the current than 
upstream, especially if one has very limited resources.


 Moreover, just think about what will happen when people see 1.0 and 
 expect to see a well-defined language specification, and maybe even to 
 be ready to write a D compiler themselves.  When they find themselves 
 disappointed, just how bad will the negative image be, and how much work 
 will it take to get rid of it?  Moreover, how will compiler writers, and 
 software houses wanting to adopt D, know when it's OK to come back?


The language spec doesn't need to be at the level of precision of the 
ISO specs (which took many years and the efforts of a couple dozen 
people) to produce. People have written compilers for languages with far 
less. The existence of a stable, reference compiler makes the 
difference, and these days, having an open source one is key.


 Yet another criterion to consider is that the language lives up to its 
 claims.  One of your claims is to make it likely that multiple, correct 
 implementations will be available.  This is impossible as long as the 
 spec still has a number of ill-defined bits.


No, it's not impossible at all. Heck, I've implemented many compilers 
for ill-defined languages (including C and C++). I agree the spec is far 
from perfect, but is it bad enough that it impedes the reasonable 
learning of D? I don't think so, as the D users do not seem to be having 
an unreasonable time learning it.



 OTOH, how many people have you counted who have dismissed D just because 
 it isn't at 1.0?


A lot. I don't have a count.


 Did any of these people tell you that they would come 
 back at 1.0 no matter what condition 1.0 is in?  I'd be surprised.


D is probably the most powerful language that ever was at 1.0.
Sep 03 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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).

 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.


It's a lot more than that. It means "this release is officially blessed 
for building libraries". Right now there are libraries which only work 
for (say) DMD 0.153 - 0.162, and others which only work for 0.148-0.155.
1.0 is an announcement that all existing libraries need to be updated, 
and that in the future, they won't be built against completely arbitrary 
versions.
Sep 04 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
Sep 04 2006
parent Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:

 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.


Me too. If we know that things in the future are going to break, we want 
to break them now if at all possible.

   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
Sep 04 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
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.


This is almost OT, but for several Java coders I know, not being able to 
type

new int[3][4][5]

and

new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
}

made a _far_ worse first impression than the version number (as in, 
quote, "you're kidding, right?"). And it seems so simple to implement.. 
If you ask me, you really need to add those before going 1.0 (it's bad 
enough for Javans that Interface[] is not Object[] ;)


xs0
Sep 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:

 This is almost OT, but for several Java coders I know, not being able to 
 type
 
 new int[3][4][5]
 
 and
 
 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }
 
 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to implement.. 
 If you ask me, you really need to add those before going 1.0 (it's bad 
 enough for Javans that Interface[] is not Object[] ;)


My experiences with people who won't use D because it doesn't have 
specific feature X is that they won't use it when feature X is 
implemented, or when Y, Z, A, B and C are implemented. They're used to 
the language they currently use, and will never change.

We can easily get sucked into a rat race trying to please people who 
haven't the slightest inclination to use D (or any language other than 
the one they currently use).

I'd much rather work on the features the people who have *already* 
switched to D need to do outrageously cool things.

You mean Java doesn't have free functions? No out parameters? No nested 
functions? No templates? No versioning? No operator overloading? No lazy 
evaluation? No 80 bit floats? No stack allocation? No structs? No array 
slicing? No direct access to C? You're kidding, right? <g>
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 xs0 wrote:

 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)


 
 My experiences with people who won't use D because it doesn't have 
 specific feature X is that they won't use it when feature X is 
 implemented, or when Y, Z, A, B and C are implemented. They're used to 
 the language they currently use, and will never change.


Oh no, not the same old story.


 
 We can easily get sucked into a rat race trying to please people who 
 haven't the slightest inclination to use D (or any language other than 
 the one they currently use).


This sure wouldn't be a good thing, but...


 
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.


I have been programming in D for years and I love it. It is just great 
how D does arrays. Well, most of the time.

We have such a great language that can do so many cool things with 
arrays. Yes but to be able to do something with an array you first have 
to create an array. And this task is incredibly difficult for such a 
basic thing in such a high level language.

Creating arrays and filling them with data sucks in D (I am saying that 
as someone who is programming in D (although not as much as I would like 
to)). 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.



 
 You mean Java doesn't have free functions? No out parameters? No nested 
 functions? No templates? No versioning? No operator overloading? No lazy 
 evaluation? No 80 bit floats? No stack allocation? No structs? No array 
 slicing? No direct access to C? You're kidding, right? <g>


D has dynamically resizable arrays, you can slice them, pass them around 
without no problems, add extension methods to them, but you can't 
initialize them? Who is kidding here? <g>
Sep 04 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Sep 04 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:

 xs0 wrote:

 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)


 
 My experiences with people who won't use D because it doesn't have 
 specific feature X is that they won't use it when feature X is 
 implemented, or when Y, Z, A, B and C are implemented. They're used to 
 the language they currently use, and will never change.
 
 We can easily get sucked into a rat race trying to please people who 
 haven't the slightest inclination to use D (or any language other than 
 the one they currently use).


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.


 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.



 You mean Java doesn't have free functions? No out parameters? No nested 
 functions? No templates? No versioning? No operator overloading? No lazy 
 evaluation? No 80 bit floats? No stack allocation? No structs? No array 
 slicing? No direct access to C? You're kidding, right? <g>


I 100% agree Java is lacking in many ways (and to be fair, it has some 
advantages, too), but if you're aiming for a good first impression, you 
also need to care of the basic stuff. The two things I mentioned seem so 
basic for a language with dynamic arrays, that I totally fail to 
understand why you're so reluctant to implement them; considering the 
unofficial wish list, I'm not the only one. 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

int[][][] foo;
foo.length = 3;
for (int a=0; a<3; a++) {
     foo[a].length = 4;
     for (int b=0; b<4; b++)
         foo[a][b].length = 5;
}


xs0
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:

 Walter Bright wrote:

 xs0 wrote:

 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)


 My experiences with people who won't use D because it doesn't have 
 specific feature X is that they won't use it when feature X is 
 implemented, or when Y, Z, A, B and C are implemented. They're used to 
 the language they currently use, and will never change.

 We can easily get sucked into a rat race trying to please people who 
 haven't the slightest inclination to use D (or any language other than 
 the one they currently use).


 
 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.
 

 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.


 

 You mean Java doesn't have free functions? No out parameters? No 
 nested functions? No templates? No versioning? No operator 
 overloading? No lazy evaluation? No 80 bit floats? No stack 
 allocation? No structs? No array slicing? No direct access to C? 
 You're kidding, right? <g>


 
 I 100% agree Java is lacking in many ways (and to be fair, it has some 
 advantages, too), but if you're aiming for a good first impression, you 
 also need to care of the basic stuff. The two things I mentioned seem so 
 basic for a language with dynamic arrays, that I totally fail to 
 understand why you're so reluctant to implement them; considering the 
 unofficial wish list, I'm not the only one. 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.
Sep 04 2006
parent reply xs0 <xs0 xs0.com> writes:
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
Sep 04 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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 :)
Sep 04 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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?
Sep 04 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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?



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
Sep 04 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:


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


The answer is not as interesting - it was chosen when the company got 
started for reasons of easier portability between platforms and ease of 
learning (it started with some physics-related stuff, so at the time it 
was decided it's better to hire physicists and teach them to code rather 
than vice-versa).

Currently, porting the existing codebase is not really an option (the 
customers are satisfied enough with the Java version), while for new 
projects the management consistently decides it's better to go with a 
language/platform everybody here knows already, to minimize risk and 
maximize productivity (that Java is strictly used is more of an 
observation than a policy).

BTW, I still think you should add those array features, even though you 
decided to snip most of my post :P


xs0
Sep 05 2006
parent Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:

 BTW, I still think you should add those array features,


I probably will.


 even though you 
 decided to snip most of my post :P


Please don't regard that as indicative of much of anything. I reply to 
posts generally mindful of how things will wind up in the archives pages 
which aggregate threads into one giant page. It looks better when 
previous article quoting is kept to the barest minimum, because the full 
text of the replied to article is right there anyway.
Sep 06 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
xs0 wrote:

 Now, consider the remarkable similarity between that case and "auto foo 
 = new int[3][4][5]" versus
 
 int[][][] foo;
 foo.length = 3;
 for (int a=0; a<3; a++) {
     foo[a].length = 4;
     for (int b=0; b<4; b++)
         foo[a][b].length = 5;
 }
 
 
 xs0


That's a really bad comparison/argument, I believe you can template that 
code such that something like this can be used:

   auto foo = newAr!(int[3][4][5])();


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 05 2006
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:
...

 
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.
 ...


The only thing I can think of that D is missing is run-time 
specification of type, and that doesn't seem as if it would 
easily fit in with the rest of D.  Possibly for D 2.0 *or* 3.0.

What I would really *LIKE* is an interim way of connecting 
easily to Python or Ruby (either one!).  Something like what 
Pyrex does for Python.  (Yes, I know that's also an absurd 
request...but that might be handleable with a library.  Perhaps.)

What's needed now, as we approach RC1, is a DEPENDABLY STABLE 
language.  That, and a big push on libraries.  When I decide 
which language to use, libraries are generally the deciding 
point.  (Not always...just recently is was the lack of 
run-time typing, but that's rarely an issue, and libraries are 
more significant.)
Sep 04 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Sep 04 2006
prev sibling next sibling parent reply "BLS" <lietz wanadoo.fr> writes:
Hi Walter,
I think your question  should be dedicated to the library developers,
because :
D needs more stable libraries.
Library development needs a feature freeze so ask them what is needed to
create well designed long living libs. Implement it and name it 1.0.

Bjoern


"Walter Bright" <newshound digitalmars.com> schreef in bericht
news:edctpl$12jt$1 digitaldaemon.com...

 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.
Sep 03 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:

 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.
 
 Bjoern
 
 
 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...

 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.


 
 


/signed as a proposal

Kris? Sean?

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
Hi Kyle,
Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
The answere is :Not at all ! What about . DWT, DTL, some not yet written
native libs, and of
course the Java to D stuff.
IMO Lib.-Development requires a lot of time. So wether Walter named 166
1.0 including a feature freeze, or  he decided to implement requested
features until 1.0, again feature freezed.

Bjoern

"Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
news:edea7q$2858$1 digitaldaemon.com...

 BLS wrote:

 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...

 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.




 /signed as a proposal

 Kris? Sean?

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:

 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.
 
 Bjoern
 
 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...

 BLS wrote:

 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...

 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.




 /signed as a proposal

 Kris? Sean?

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright


 
 


I mentioned Kris and Sean since they have some of the most extensive, 
public, and mature library code in the D community, of course, this 
doesnt marginalize the voice of other library writers.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
Well Kyle.
D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
(Commercial) Success ->
 D-LanguageEvolution -> (loop)
So what do whe have  here : A  typical chaotic self-dynamic process.
(Feature Freeze !)
Bjoern



"Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
news:edeqqn$2mbb$1 digitaldaemon.com...

 BLS wrote:

 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is




me :

 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.

 Bjoern

 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...

 BLS wrote:

 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed








to

 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...

 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.




 /signed as a proposal

 Kris? Sean?

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright




 I mentioned Kris and Sean since they have some of the most extensive,
 public, and mature library code in the D community, of course, this
 doesnt marginalize the voice of other library writers.

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:

 Well Kyle.
 D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
 D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
 (Commercial) Success ->
  D-LanguageEvolution -> (loop)
 So what do whe have  here : A  typical chaotic self-dynamic process.
 (Feature Freeze !)
 Bjoern
 
 
 
 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edeqqn$2mbb$1 digitaldaemon.com...

 BLS wrote:

 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is




 me :

 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.

 Bjoern

 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...

 BLS wrote:

 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed








 to

 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...

 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.




 /signed as a proposal

 Kris? Sean?

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright




 I mentioned Kris and Sean since they have some of the most extensive,
 public, and mature library code in the D community, of course, this
 doesnt marginalize the voice of other library writers.

 -- 
 Kyle Furlong // Physics Undergrad, UCSB

 "D is going wherever the D community wants it to go." - Walter Bright


 
 


Nice break down, I believe it is time to move to the library building 
phase in earnest, so like you said, RC1 it is.

-- 
Kyle Furlong // Physics Undergrad, UCSB

"D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
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.


I'm in favor of a spec feature freeze now and considering that 1.0.  A 
few refinements may be worthwhile here and there, but I don't see the 
need for any actual new features at this point.


Sean
Sep 03 2006
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.


Firstly, I don't think things like fancy delegates with functional 
programming are very important for 1.0.  They are cool, but can wait.

I see some things that should be implemented before RC1 for backwards 
compatibility reasons, like auto and constness.  There is a way around 
that for the most part though:

I would like to see an experimental branch before seeing an RC, sort of 
like Gregor suggested.  Not a branch of the compiler, but a branch of 
the spec.  Features that are not stable or not implemented yet would 
fall into this experimental branch.  There would be a singular DMD that 
conforms to this spec, with the realization that any feature from the 
experimental part of the spec my change in the next release.

Here are some things I'd expect to see in the experimental spec:
- Lazy delegates // very new stuff
- auto // due to auto auto, this will get changed sometime right?
- array operators // not implemented yet
- common func ptr/delegate syntax // not implemented yet
- IFTI // not fully implemented
- mixins // I've read complaints about the usability of mixins
and so on...

It may even be nice to have a couple phases of experimental spec, like 
an alpha spec and a beta spec.  The alpha spec contains things that will 
most likely change, and the beta spec contains fairly stable features 
that are yet to be time-tested.

This would allow 1.0 to roll out without some of those things I've 
listed being addressed.  I don't think those features I've mentioned as 
experimental spec candidates are super important.  The only reason we 
worry about some of these, like auto auto, are for backwards 
compatibility.  But with an experimental system, coders are prewarned, 
and backwards compatibility isn't too worrisome.  Still, something like 
constness still bugs me even with experimental spec, since it could 
change very basic things about the language.


If 1.0 isn't a publicity thing, then disregard the below.  These assume 
that many new programmers will be trying D when a 1.0 release happens, 
and will need impressing.

Another big problem I see with RC1 - Access violation.  If there is 
going to be a mob of people trying D at 1.0, then the compiler should 
behave nicely, and not produce programs that produce 'access violation'. 
  This seems very tacky to me.  It turns a 30 second code correction 
into a 10+ minute debugging session, ouch!  At least put line numbers on 
those things.  Bonus points for decent descriptions of what went wrong.

Also related to mobs of people trying D at 1.0 - the spec needs going 
over with a fine tooth comb.  This seems to be going on already, which 
is good.  The spec's coolness would go up a few notches if there was a 
spec-only keyword search option.  Do this *before* 1.0.

Phobos.  Maybe this can wait, but perhaps we should at least do some 
work to phobos' interface?  Make sure the naming is consistent with the 
D style guidelines.  It needs a *simple* way to read input from the 
console, and not some std.c.crap.  Also, 'atoi' (in std.string) is a 
horrible name for a function that turns a string into an integer, and we 
have overloading now, unlike C back in the day, so make it 'toInt' 
(which exists in std.conv, so why the dupe?).  This shouldn't be a big 
effort to expand phobos' functionality, just a time where we break 
everyone's code and deal with it so that future D programmers don't have 
to.  Adopting another library like Ares as standard and tweaking on it 
should work too, though I see that as harder to pull off.
Sep 03 2006
parent Kristian <kjkilpi gmail.com> writes:
I agree.
Especially things that will/could break backward compability should be  
considered now. (Later these things are of course harder to change: 1) it  
cannot be done, 2) it'll break backward compability (e.g. 1.0 code doesn't  
compile with 1.1), and 3) old syntax (marked as obsolete) exists parallel  
with the new one.)

On Mon, 04 Sep 2006 00:01:27 +0300, Chad J  
<gamerChad _spamIsBad_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.


 Firstly, I don't think things like fancy delegates with functional  
 programming are very important for 1.0.  They are cool, but can wait.

 I see some things that should be implemented before RC1 for backwards  
 compatibility reasons, like auto and constness.  There is a way around  
 that for the most part though:

 I would like to see an experimental branch before seeing an RC, sort of  
 like Gregor suggested.  Not a branch of the compiler, but a branch of  
 the spec.  Features that are not stable or not implemented yet would  
 fall into this experimental branch.  There would be a singular DMD that  
 conforms to this spec, with the realization that any feature from the  
 experimental part of the spec my change in the next release.

 Here are some things I'd expect to see in the experimental spec:
 - Lazy delegates // very new stuff
 - auto // due to auto auto, this will get changed sometime right?
 - array operators // not implemented yet
 - common func ptr/delegate syntax // not implemented yet
 - IFTI // not fully implemented
 - mixins // I've read complaints about the usability of mixins
 and so on...

 It may even be nice to have a couple phases of experimental spec, like  
 an alpha spec and a beta spec.  The alpha spec contains things that will  
 most likely change, and the beta spec contains fairly stable features  
 that are yet to be time-tested.

 This would allow 1.0 to roll out without some of those things I've  
 listed being addressed.  I don't think those features I've mentioned as  
 experimental spec candidates are super important.  The only reason we  
 worry about some of these, like auto auto, are for backwards  
 compatibility.  But with an experimental system, coders are prewarned,  
 and backwards compatibility isn't too worrisome.  Still, something like  
 constness still bugs me even with experimental spec, since it could  
 change very basic things about the language.


 If 1.0 isn't a publicity thing, then disregard the below.  These assume  
 that many new programmers will be trying D when a 1.0 release happens,  
 and will need impressing.

 Another big problem I see with RC1 - Access violation.  If there is  
 going to be a mob of people trying D at 1.0, then the compiler should  
 behave nicely, and not produce programs that produce 'access violation'.  
   This seems very tacky to me.  It turns a 30 second code correction  
 into a 10+ minute debugging session, ouch!  At least put line numbers on  
 those things.  Bonus points for decent descriptions of what went wrong.

 Also related to mobs of people trying D at 1.0 - the spec needs going  
 over with a fine tooth comb.  This seems to be going on already, which  
 is good.  The spec's coolness would go up a few notches if there was a  
 spec-only keyword search option.  Do this *before* 1.0.

 Phobos.  Maybe this can wait, but perhaps we should at least do some  
 work to phobos' interface?  Make sure the naming is consistent with the  
 D style guidelines.  It needs a *simple* way to read input from the  
 console, and not some std.c.crap.  Also, 'atoi' (in std.string) is a  
 horrible name for a function that turns a string into an integer, and we  
 have overloading now, unlike C back in the day, so make it 'toInt'  
 (which exists in std.conv, so why the dupe?).  This shouldn't be a big  
 effort to expand phobos' functionality, just a time where we break  
 everyone's code and deal with it so that future D programmers don't have  
 to.  Adopting another library like Ares as standard and tweaking on it  
 should work too, though I see that as harder to pull off.
Sep 03 2006
prev sibling next sibling parent Mikola Lysenko <mclysenk mtu.edu> writes:
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.


I vote for fixing the current D language specification as "1.0," barring 
the discovery of some horrible ambiguity or logical inconsistency. 
Future changes should still be considered, but I think we need to go 
through a few rounds of clean up and bug fixing before we start mutating 
again.  The language is still not as mature as C++ or Java, and it is 
only natural that it will need further revisions.

That said, the compilers need to catch up.  GDC is always bit behind, 
and DMD has several outstanding problems on Linux.  Letting things cook 
for a few releases would settle this out and improve overall confidence.

Also, this would put more attention on library development within the 
community, which is desperately needed.  Phobos is still missing several 
key components such as a GUI and templated containers.  What remains is 
not very trustworthy.  The only two modules I feel comfortable using 
right now are std.stdio and std.math.  The rest are highly suspect, 
especially std.thread.

There needs to be much more critical attention toward the library and 
runtime, and less pointless bickering over what new features to include. 
  In other words, it is time to stop worrying about what D should do, 
and time to discover what it can do.
Sep 03 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
Sep 04 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
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 calli=




ng  =


 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 =3D 11;
      int opIndex(int pos){return xx;}
      int opIndexAssign(int what, int pos){return xx =3D what;}

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

    auto a =3D 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 case=


s  =


 to (and shouldn't be that hard to do):

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

 auto y =3D a.prop;
    f(y);
 a.prop =3D 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 becau=
se  =

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.)
Sep 04 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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).
Sep 04 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 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.


Hmm, I'm going to have to look into it a little bit further. I 
understand the potential problems with the compiler converting this. But 
isn't also a change from a field to a property that breaks existing code 
also a problem (maybe even a bigger one)? This has happened to me more 
than once.

Inout means return a value through the param? I agree, but it is a 
limitation that it cannot be returned into property.

The compiler could always issue a nice warning message if read or write 
property is missing.


 
 It's an error in C++ for the same reason (can't initialize a reference 
 with a non-const).
Sep 04 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:


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


You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
In fact, it could have been one until the class author changed it to a
property.  I feel that Properties need to behave as if they were data
members rather than methods when used as such. Thus ...

  f(a.prop);
and
  f(a.prop());

would look *and* behave differently but without surprising the coder.

And this also means that 

  a.prop++

needs to work too. It is a great surprise to new comers that obvious things
like this are not working as expected.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 04 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Derek Parnell wrote:

 On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:
 

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


 
 You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...
 
   f(a.prop);
 and
   f(a.prop());
 
 would look *and* behave differently but without surprising the coder.
 
 And this also means that 
 
   a.prop++
 
 needs to work too. It is a great surprise to new comers that obvious things
 like this are not working as expected.
 


And what about:

a.prop.y = 7;

Where prop is/returns a struct { int x,y; } ?

-- 
Oskar
Sep 04 2006
next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Oskar Linde wrote:

 Derek Parnell wrote:
 

 On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:


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



 You are right Walter. However, a[5] looks looks like an lvalue doesn't 
 it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...

   f(a.prop);
 and
   f(a.prop());

 would look *and* behave differently but without surprising the coder.

 And this also means that
   a.prop++

 needs to work too. It is a great surprise to new comers that obvious 
 things
 like this are not working as expected.


 
 And what about:
 
 a.prop.y = 7;
 
 Where prop is/returns a struct { int x,y; } ?
 


I'm not a fan of the current property syntax either.  I'd be very happy 
to see Walter implement get/set syntax, or some such.  I just can't say 
this is a 1.0 issue though, unless it's going to be tough to rewrite 
code when it's changed.

Are there plans to change this in the future?
Sep 04 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Oskar Linde wrote:

 Derek Parnell wrote:
 

 On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:


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



 You are right Walter. However, a[5] looks looks like an lvalue doesn't 
 it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...

   f(a.prop);
 and
   f(a.prop());

 would look *and* behave differently but without surprising the coder.

 And this also means that
   a.prop++

 needs to work too. It is a great surprise to new comers that obvious 
 things
 like this are not working as expected.


 
 And what about:
 
 a.prop.y = 7;
 
 Where prop is/returns a struct { int x,y; } ?
 


Easy enough, return a pointer to the struct.

But still.

-- Chris Nicholson-Sauls
Sep 04 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

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


 
 You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...
 
   f(a.prop);
 and
   f(a.prop());
 
 would look *and* behave differently but without surprising the coder.
 
 And this also means that 
 
   a.prop++
 
 needs to work too. It is a great surprise to new comers that obvious things
 like this are not working as expected.


Whether it's consistent or not depends on how you think about it - what 
your mental model is of it. I'd rather have the odd cases produce error 
messages rather than have the compiler paper over what is likely a 
programmer oversight.
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

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


 You are right Walter. However, a[5] looks looks like an lvalue doesn't 
 it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...

   f(a.prop);
 and
   f(a.prop());

 would look *and* behave differently but without surprising the coder.

 And this also means that
   a.prop++

 needs to work too. It is a great surprise to new comers that obvious 
 things
 like this are not working as expected.


 
 Whether it's consistent or not depends on how you think about it - what 
 your mental model is of it. I'd rather have the odd cases produce error 
 messages rather than have the compiler paper over what is likely a 
 programmer oversight.


Hmm, inconsistent is: changing a field to a property -> some code 
doesn't need to change, some code needs to change.

It seems that your mental model is that properties and the result of 
opIndex/opIndexAssign behaving like normal lvalues is the odd case?
Well in my mental model them behaving like lvalues is a normal case, and 
the current behavior is a wtf.

Actually I would like to know what this sentence of yours means:
"If the user calls a function with a parameter that cannot accept such a 
return value, it is most likely a mistake."

Does it mean if a property is passed that doesn't have a setter method? 
I would expect that to be reported at compile time as a nice "cannot 
pass read-only property as lvalue".

Is there an example where replacing

f(a.prop);

with

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

would be a bad thing to do, and could result in unexpected code, or hard 
to catch bugs.
Sure some aspects of this behavior should be well documented to avoid 
confusion (like the fact that the value is updated on function exit) but 
it is the same with most other feature.

To make myself clear: D can do without this feature but without it a simple:

write f(a.prop) -> compile&run happily

is replaced with

write f(a.prop) -> compile -> goto line with error -> figure out the 
error and how to fix it (might be hard the first time) ->
select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
compile&run (but less happily now)
Sep 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:

 Is there an example where replacing
 
 f(a.prop);
 
 with
 
 auto x=a.prop; f(x); a.prop=x;
 
 would be a bad thing to do, and could result in unexpected code, or hard 
 to catch bugs.
 Sure some aspects of this behavior should be well documented to avoid 
 confusion (like the fact that the value is updated on function exit) but 
 it is the same with most other feature.
 
 To make myself clear: D can do without this feature but without it a 
 simple:
 
 write f(a.prop) -> compile&run happily
 
 is replaced with
 
 write f(a.prop) -> compile -> goto line with error -> figure out the 
 error and how to fix it (might be hard the first time) ->
 select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
 compile&run (but less happily now)


I'd ask "why is f(x) returning a value in x?" That would normally be an 
essential part of the behavior of the function, so:
	f(3)
should return an error, shouldn't it? If modifying its argument is an 
essential behavior of the function, and the argument is not modifiable, 
probably the programmer made a mistake and the compiler should not paper 
it over. And the same for every other argument that isn't an lvalue (and 
so cannot be set).

If you find yourself writing:

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

I would seriously question what is going on with f(). It's a big flag 
that something is wrong either with f() or with the usage of f(). I 
would not want the compiler papering it over.
Sep 04 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
On Mon, 04 Sep 2006 15:44:52 -0700, Walter Bright wrote:


 Ivan Senji wrote:

 Is there an example where replacing
 
 f(a.prop);
 
 with
 
 auto x=a.prop; f(x); a.prop=x;
 
 would be a bad thing to do, and could result in unexpected code, or hard 
 to catch bugs.
 Sure some aspects of this behavior should be well documented to avoid 
 confusion (like the fact that the value is updated on function exit) but 
 it is the same with most other feature.
 
 To make myself clear: D can do without this feature but without it a 
 simple:
 
 write f(a.prop) -> compile&run happily
 
 is replaced with
 
 write f(a.prop) -> compile -> goto line with error -> figure out the 
 error and how to fix it (might be hard the first time) ->
 select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
 compile&run (but less happily now)


 
 I'd ask "why is f(x) returning a value in x?" That would normally be an 
 essential part of the behavior of the function, so:
 	f(3)
 should return an error, shouldn't it? If modifying its argument is an 
 essential behavior of the function, and the argument is not modifiable, 
 probably the programmer made a mistake and the compiler should not paper 
 it over. And the same for every other argument that isn't an lvalue (and 
 so cannot be set).
 
 If you find yourself writing:
 
     auto x=a.prop; f(x); a.prop=x;
 
 I would seriously question what is going on with f(). It's a big flag 
 that something is wrong either with f() or with the usage of f(). I 
 would not want the compiler papering it over.


What a load of BS. The user of 'prop' does not need to know how it's been
implemented. 

class A
{
   int prop;
}

class B 
{
    private int q;
    void prop(int x) { q = x; }
    int prop() { return q; }
}

void f(inout int x)
{
    if (x < 0)
       x = -x;
}

A a = new A;
B b = new B;

f(a.prop);  // okay
f(b.prop);  // fubar




-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 04 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 
 I'd ask "why is f(x) returning a value in x?" That would normally be an 
 essential part of the behavior of the function, so:
     f(3)
 should return an error, shouldn't it? 


Sure.


 If modifying its argument is an 
 essential behavior of the function, and the argument is not modifiable, 
 probably the programmer made a mistake and the compiler should not paper 
 it over. 


Sure, but properties can be modifiable.


 And the same for every other argument that isn't an lvalue (and 
 so cannot be set).
 
 If you find yourself writing:
 
    auto x=a.prop; f(x); a.prop=x;
 
 I would seriously question what is going on with f(). It's a big flag 
 that something is wrong either with f() or with the usage of f(). I 
 would not want the compiler papering it over.


I don't really understand why this should be a flag that something is 
wrong with f. There are probably good reasons why f isn't a member 
function, it is a generic algorithm.
Sep 04 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
On Mon, 04 Sep 2006 15:15:15 -0700, Walter Bright wrote:


 Derek Parnell wrote:

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


 
 You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...
 
   f(a.prop);
 and
   f(a.prop());
 
 would look *and* behave differently but without surprising the coder.
 
 And this also means that 
 
   a.prop++
 
 needs to work too. It is a great surprise to new comers that obvious things
 like this are not working as expected.


 
 Whether it's consistent or not depends on how you think about it - what 
 your mental model is of it. I'd rather have the odd cases produce error 
 messages rather than have the compiler paper over what is likely a 
 programmer oversight.


What 'odd case'?

What 'programmer oversight'?

The coder writes 

  a.prop++;

because the 'prop' is a data item in the object that she wants to
increment. It is irrelevant to the coder whether or not the class author
decided to implement this data item as a property or data member. From the
perspective of the user of the class, 'prop' represents some data in the
object. The implementation details are not a concern for the user of the
class. 

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 04 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Tue, 05 Sep 2006 02:16:46 +0300, Derek Parnell <derek psyc.ward> wrote:


 On Mon, 04 Sep 2006 15:15:15 -0700, Walter Bright wrote:


 Derek Parnell wrote:

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


 You are right Walter. However, a[5] looks looks like an lvalue doesn't  
 it?
 In fact, it could have been one until the class author changed it to a
 property.  I feel that Properties need to behave as if they were data
 members rather than methods when used as such. Thus ...

   f(a.prop);
 and
   f(a.prop());

 would look *and* behave differently but without surprising the coder.

 And this also means that

   a.prop++

 needs to work too. It is a great surprise to new comers that obvious  
 things
 like this are not working as expected.


 Whether it's consistent or not depends on how you think about it - what
 your mental model is of it. I'd rather have the odd cases produce error
 messages rather than have the compiler paper over what is likely a
 programmer oversight.


 What 'odd case'?

 What 'programmer oversight'?

 The coder writes

   a.prop++;

 because the 'prop' is a data item in the object that she wants to
 increment. It is irrelevant to the coder whether or not the class author
 decided to implement this data item as a property or data member. From  
 the
 perspective of the user of the class, 'prop' represents some data in the
 object. The implementation details are not a concern for the user of the
 class.


I agree fully. I thought that the whole point was to hide the  
implementation from the user.

I sent a message "Suggestion: properties should be treated as 'virtual  
members variables'" to digitalmars.D concerning this issue (I think it  
deserves its own thread).

(I know that I have sent these suggestions quite many, hopefully nobody  
thinks that I'm raving that these features must be in D or it'll suck, or  
something... ;) I hope that they will -- at least -- cause discussion that  
could lead to new ideas and improvements for this great language.)
Sep 05 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 What 'odd case'?
 
 What 'programmer oversight'?
 
 The coder writes 
 
   a.prop++;
 
 because the 'prop' is a data item in the object that she wants to
 increment. It is irrelevant to the coder whether or not the class author
 decided to implement this data item as a property or data member. From the
 perspective of the user of the class, 'prop' represents some data in the
 object. The implementation details are not a concern for the user of the
 class. 
 


Oh, I see what you mean now. I had misunderstood. Sorry.
Sep 05 2006
next sibling parent Ary Manzana <asterite gmail.com> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 What 'odd case'?

 What 'programmer oversight'?

 The coder writes
   a.prop++;

 because the 'prop' is a data item in the object that she wants to
 increment. It is irrelevant to the coder whether or not the class author
 decided to implement this data item as a property or data member. From 
 the
 perspective of the user of the class, 'prop' represents some data in the
 object. The implementation details are not a concern for the user of the
 class.


 
 Oh, I see what you mean now. I had misunderstood. Sorry.


What's the problem here? Is it hard to implement in the compiler or is 
unexpected behavior the problem? I think nowhere is unexpected behavior 
in "a.prop++". Just translate it to "a.prop = a.prop + 1".

If "a.prop" is a time consuming one, it should be great to be able to 
override the "++" and "--" meaning of the property, so that a 1 can be 
added or subtracted internally more efficiently. However, I can't 
imagine what the syntax could look like...

Ary
Sep 05 2006
prev sibling parent Derek Parnell <derek psyc.ward> writes:
On Tue, 05 Sep 2006 12:40:47 -0700, Walter Bright wrote:


 Oh, I see what you mean now. I had misunderstood. Sorry.


That's ok. I have a huge problem with electronic expression. If we could
talk face to face I wouldn't be nearly so obscure ;-)

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
Sep 05 2006