www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Changes before 1.0

reply Jordan Miner <jminer2613 no.spam.students.pcci.edu> writes:
Hello, I have been reading this newsgroup on and off for over a year, but this
is my first post. I first found D because I got fed up with the VMs of Java

language that compiled to native code, but was easier to use than C++, and I
found D within minutes.
When I first started using D, there were many parts I though could be
improved, but I am OK with most of them now. I have been working on a GUI
library for D for months now, but I don't want to release it until it is
usable. While working on it, I have run into several things in D that I wish
were changed. Here are a few I think could be added before 1.0.

--1--
The following does not work, but it really should:
	void print(char[][] strs) { }
	print(["Matt", "Andrew"]);
Gives:
	Error: cannot implicitly convert expression ("Andrew") of type char[6] to
char[4]
--2--
Sometimes using the property syntax causes a compiler error:
	with(obj.propName) {  // gives an error without parentheses
	}
	auto foo = obj.propName; // gives an error without parentheses
These are common uses of property syntax, and I think they should work.
--3--
I noticed one day that this kind of a loop is fairly common:
	while(true) {
		doSomething();
		if(!shouldContinue)
			break;
		doSomethingElse();
	}
It might be better to make an extended do-while loop that has code before and
after the condition:
	do {
		doSomething();
	} while(shouldContinue) {
		doSomethingElse();
	}
The latter is shorter and IMO cleaner.
--4--
It would be helpful if the following code would work:
	enum TestEnum {
		Value1, Value2
	}
	writefln("%s", TestEnum.Value2);
It should print "Value2", but instead gives:
	Error: std.format formatArg

so I tried printing it and I got the name of the enum member.
	enum TestEnum {
		Value1, Value2
	}
	Console.WriteLine(TestEnum.Value2);
This prints "Value2" with .NET.
--5--
I know that it has been brought up before, but I would like to add my support
to this being put into object.d:
	alias char[] string;
-----

I also really want stack traces for exceptions/access violations and big Ddoc
improvements, but those don't change the language and can wait until after
1.0. I would also really really like to have closures/static delegates, but
that would probably take some time, what with escape analysis and all. BTW, I
really like how Walter wants to implement them--with the current delegate
syntax using escape analysis. D will be amazing then.
Dec 02 2006
next sibling parent reply Miles <_______ _______.____> writes:
Jordan Miner wrote:

 Sometimes using the property syntax causes a compiler error:


Properties are also broken for cases like:

	button.width -= 5;
	cursor.position++;

This is the essence of properties (it should be completely transparent
for the user if it is accessing a variable or calling a method), yet D
doesn't support it properly. This has the potential to break a lot of
code when you convert variables into properties.


 	do {
 		doSomething();
 	} while(shouldContinue) {
 		doSomethingElse();
 	}


Interleaving. But it would be pretty useless if the two blocks had
different scopes.


 	enum TestEnum {
 		Value1, Value2
 	}
 	writefln("%s", TestEnum.Value2);


IMO, a nice way to bloat your executable code. I'd recommend placing
this feature on a debugger, and the string repr of enums should be debug
data. If you need string equivalence for enums, you should put them in a
separate string array, and just index it with the enum. This allows
better description of values and also makes l10n more straightforward.
Dec 02 2006
next sibling parent Jordan Miner <jminer2613 no.spam.students.pcci.edu> writes:
== Quote from Miles (_______ _______.____)'s article

 Jordan Miner wrote:

 Sometimes using the property syntax causes a compiler error:


 Properties are also broken for cases like:
 	button.width -= 5;
 	cursor.position++;
 This is the essence of properties (it should be completely transparent
 for the user if it is accessing a variable or calling a method), yet D
 doesn't support it properly. This has the potential to break a lot of
 code when you convert variables into properties.


Yes, it would be great if operators would work with them as well.


 	do {
 		doSomething();
 	} while(shouldContinue) {
 		doSomethingElse();
 	}


 Interleaving. But it would be pretty useless if the two blocks had
 different scopes.


Yeah, this was just an idea I had, and I thought that it would be easy to
implement. And it would definitely be best if both blocks had the same scope.


 	enum TestEnum {
 		Value1, Value2
 	}
 	writefln("%s", TestEnum.Value2);


 IMO, a nice way to bloat your executable code. I'd recommend placing
 this feature on a debugger, and the string repr of enums should be debug
 data. If you need string equivalence for enums, you should put them in a
 separate string array, and just index it with the enum. This allows
 better description of values and also makes l10n more straightforward.


Yes, the only time I wanted this was during debugging. Otherwise it can be
difficult to find out which enum name a variable is. .NET's docs do not say enum
values, and the source is not available. Even with D, it is more convinient to
just put writefln("%s", variable) to find out. (I don't use debuggers.) Any
other
time I need the description of an enum, I would use a string array.
Dec 02 2006
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Personally, I think it wouldn't be hard for the compiler to do this for 
you, but only bloat your code with it if it's ever used.

For example:

enum Example;

writefln("%s", Example.names[some_value]);

Or whatever.  Then again, maybe it's non-trivial to detect the usage.  I 
wouldn't think so, though.

-[Unknown]



 IMO, a nice way to bloat your executable code. I'd recommend placing
 this feature on a debugger, and the string repr of enums should be debug
 data. If you need string equivalence for enums, you should put them in a
 separate string array, and just index it with the enum. This allows
 better description of values and also makes l10n more straightforward.
Dec 02 2006
prev sibling next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Miles wrote:

 Jordan Miner wrote:

 Sometimes using the property syntax causes a compiler error:


 
 Properties are also broken for cases like:
 
 	button.width -= 5;
 	cursor.position++;
 
 This is the essence of properties (it should be completely transparent
 for the user if it is accessing a variable or calling a method), yet D
 doesn't support it properly. This has the potential to break a lot of
 code when you convert variables into properties.


What is sad is that with the current property syntax, D can *never* 
achieve transparency. Even if ++a.x would be transformed into 
a.x(a.x()+1) there are cases that can never be transformed into an 
"accessor" property and make the accessing code remain the same. E.g:

struct Type {
	int delegate() prop;
}

Type t;

Used:
	t.prop()


Try transforming that into an accessor property:

struct Type {
	int delegate() prop() { return { return 0; }; }
}

Now, t.prop() will have a different meaning.

The problem here is that the trailing parenthesis pair () is allowed but 
not necessary. t.prop() could mean both t.prop and t.prop()().

/Oskar
Dec 04 2006
prev sibling parent reply Leandro Lucarella <llucarella integratech.com.ar> writes:
Miles escribió:

 Jordan Miner wrote:

 Sometimes using the property syntax causes a compiler error:


 
 Properties are also broken for cases like:
 
 	button.width -= 5;
 	cursor.position++;
 
 This is the essence of properties (it should be completely transparent
 for the user if it is accessing a variable or calling a method), yet D
 doesn't support it properly. This has the potential to break a lot of
 code when you convert variables into properties.


I think you can add this to the thread "Python-like tabs instead of 
curley brackets?" where Walter says:

"Every programming language has some stupid mistake in it that sounded 
like a good idea at the time:
[other languages problems]
D: I'm sure you all have your own ideas for this!"

I mean, properties are great, but to be really useful they have to 
support the same semantics as regular variables. Maybe somethig as 
simple as translating button.width -= 5; as cursor.position = 
button.width - 5; is enough. Postfix incrementation is maybe the only 
problematic one, but could be done with something like:
{
	auto tmp = cursor.position;
	cursor.position = cursor.position + 1;
	return tmp;
}
(I think you'll get the idea ;)

This last scheme could be generally used to implement the other 
operators: 1) make a copy of the property 2) operate over the copy 3) 
update the property.

Or maybe the "stupid mistake" is deeper and it comes from the side of 
treating differently POD and objects...

-- 
Leandro Lucarella
Integratech S.A.
4571-5252
Dec 04 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Some nitpicks :)

Leandro Lucarella wrote:

 I mean, properties are great, but to be really useful they have to 
 support the same semantics as regular variables. Maybe somethig as 
 simple as translating button.width -= 5; as cursor.position = 
 button.width - 5; is enough. Postfix incrementation is maybe the only 


I think that cursor.position should be button.width...


 problematic one, but could be done with something like:
 {
     auto tmp = cursor.position;
     cursor.position = cursor.position + 1;


Surely you mean 'cursor.position = tmp + 1;'?


     return tmp;
 }
Dec 04 2006
parent reply Leandro Lucarella <llucarella integratech.com.ar> writes:
Frits van Bommel escribió:

 Some nitpicks :)
 
 Leandro Lucarella wrote:

 I mean, properties are great, but to be really useful they have to 
 support the same semantics as regular variables. Maybe somethig as 
 simple as translating button.width -= 5; as cursor.position = 
 button.width - 5; is enough. Postfix incrementation is maybe the only 


 
 I think that cursor.position should be button.width...


Yup! =)


 problematic one, but could be done with something like:
 {
     auto tmp = cursor.position;
     cursor.position = cursor.position + 1;


 
 Surely you mean 'cursor.position = tmp + 1;'?


Well, they have the same value at that point, so what's the difference?


     return tmp;
 }





-- 
Leandro Lucarella
Integratech S.A.
4571-5252
Dec 04 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Leandro Lucarella wrote:

 Frits van Bommel escribió:

 Some nitpicks :)

 Leandro Lucarella wrote:




<snip>

 problematic one, but could be done with something like:
 {
     auto tmp = cursor.position;
     cursor.position = cursor.position + 1;


 Surely you mean 'cursor.position = tmp + 1;'?


 
 Well, they have the same value at that point, so what's the difference?


Sorry, I thought cursor.position was a property?
If so, the way you wrote it the getter would be called twice as opposed 
to once with the rewrite.
If the getter returned something else the second time[1] then the 
returned value wouldn't even be one less than the new value[2].

Plus accessing a local variable is probably more efficient than calling 
a getter :).


[1]: This is probably pretty bad style, but it _is_ legal.
[2]: Unless of course the setter did something weird as well, but let's 
not get into that.
Dec 04 2006
prev sibling next sibling parent Tom <tom nospam.com> writes:
Jordan Miner wrote:

 Hello, I have been reading this newsgroup on and off for over a year, but this
 is my first post. I first found D because I got fed up with the VMs of Java

 language that compiled to native code, but was easier to use than C++, and I
 found D within minutes.


I've discovered D in a similar manner :) (only that I'm following it 
since 2004). I'm still so glad I found it.


 --4--
 It would be helpful if the following code would work:
 	enum TestEnum {
 		Value1, Value2
 	}
 	writefln("%s", TestEnum.Value2);
 It should print "Value2", but instead gives:
 	Error: std.format formatArg

 so I tried printing it and I got the name of the enum member.
 	enum TestEnum {
 		Value1, Value2
 	}
 	Console.WriteLine(TestEnum.Value2);
 This prints "Value2" with .NET.


I agree enums could be so much better.


 --5--
 I know that it has been brought up before, but I would like to add my support
 to this being put into object.d:
 	alias char[] string;


Yep, I do ALWAYS write this alias in my D programs.
Also:

alias wchar[] wstring;
alias dchar[] dstring;

--
Tom;
Dec 02 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jordan Miner schrieb am 2006-12-02:


 --1--
 The following does not work, but it really should:
 	void print(char[][] strs) { }
 	print(["Matt", "Andrew"]);
 Gives:
 	Error: cannot implicitly convert expression ("Andrew") of type char[6] to
char[4]


current by-pass:
 	print([cast(char[])"Matt", "Andrew"]);

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFFcokqLK5blCcjpWoRApj5AJsEefCVGCPbDNEbQ7w2X4o2YfFxiQCeNSMj
UrCf1EgP/ihgUeHVVOpc6go=
=Vr9o
-----END PGP SIGNATURE-----
Dec 03 2006
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Thomas Kuehne wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Jordan Miner schrieb am 2006-12-02:
 

 --1--
 The following does not work, but it really should:
 	void print(char[][] strs) { }
 	print(["Matt", "Andrew"]);
 Gives:
 	Error: cannot implicitly convert expression ("Andrew") of type char[6] to
char[4]


 
 current by-pass:
  	print([cast(char[])"Matt", "Andrew"]);
 
 Thomas
 


Or just:
   print(["Matt"[], "Andrew"]);


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 06 2006
prev sibling parent reply janderson <askme me.com> writes:
 It would be helpful if the following code would work:
 	enum TestEnum {
 		Value1, Value2
 	}
 	writefln("%s", TestEnum.Value2);


It would be even more helpful if a .ToString() for enums was added.  The 
compiler could detect when it was used and only add those particular 
enums to the binary.  It would be most useful in scripting where you 
want to convert a string to an enum.  Which leads on to having a way of 
converting a string to an enum directly.

string myenum = "Value1";
TestEnum result = myenum;

Ok getting its a bit complicated here and probably not worth the effort 
however I deal with this type of code at least once a week.  Maybe that 
would be a 2.0 feature.

-Joel
Dec 03 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:

 It would be helpful if the following code would work:
     enum TestEnum {
         Value1, Value2
     }
     writefln("%s", TestEnum.Value2);


 
 It would be even more helpful if a .ToString() for enums was added.  The 
 compiler could detect when it was used and only add those particular 
 enums to the binary.  
 It would be most useful in scripting where you
 want to convert a string to an enum.  Which leads on to having a way of 
 converting a string to an enum directly.
 
 string myenum = "Value1";
 TestEnum result = myenum;
 
 Ok getting its a bit complicated here and probably not worth the effort 
 however I deal with this type of code at least once a week.  Maybe that 
 would be a 2.0 feature.



I agree that I've wanted this kind of feature before too, but I don't 
want it at the expense of bloating every single library that contains 
enums with lots of string equivalents that will never get used in real 
code.  I.e. this kind of thing is really only useful for debug or 
prototype code.

But I think you're right, the compiler has to have access to the enum 
names in order to compile any code that uses the enums, and if it does 
then it should be able to replace something like enumval.str with the 
literal string value.  So it would act more like a macro expanded at 
compile time than an actual function.

--bb
Dec 03 2006
parent reply janderson <askme me.com> writes:
Bill Baxter wrote:

 janderson wrote:

 It would be helpful if the following code would work:
     enum TestEnum {
         Value1, Value2
     }
     writefln("%s", TestEnum.Value2);




 
 I agree that I've wanted this kind of feature before too, but I don't 
 want it at the expense of bloating every single library that contains 
 enums with lots of string equivalents that will never get used in real 
 code.  I.e. this kind of thing is really only useful for debug or 
 prototype code.
 --bb


I don't agree on this point (that it would only be used in debug).  As I 
said, in scripting  (ie game ai ect...) and in plugin libraries (ie 
maya) its common place to use a string lookup for enums.  The code isn't 
*much* longer or more bug pron to write unless you go the other way and 
want it to be efficient (ie string->enum is more complex then 
enum->string).  Still both cases are pretty trivial to write in code.

I guess the main thing going for it is that users would recognize the 
pattern much more quickly (ie readability) although it does reduce the 
chance of offset errors (had one of those just the other day).

-Joel
Dec 03 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:

 Bill Baxter wrote:

 janderson wrote:

 It would be helpful if the following code would work:
     enum TestEnum {
         Value1, Value2
     }
     writefln("%s", TestEnum.Value2);




 I agree that I've wanted this kind of feature before too, but I don't 
 want it at the expense of bloating every single library that contains 
 enums with lots of string equivalents that will never get used in real 
 code.  I.e. this kind of thing is really only useful for debug or 
 prototype code.
 --bb


 
 I don't agree on this point (that it would only be used in debug).  As I 
 said, in scripting  (ie game ai ect...) and in plugin libraries (ie 
 maya) its common place to use a string lookup for enums.  The code isn't 
 *much* longer or more bug pron 


Mmmm -- bug pr0n.  *much* longer ... more bug pr0n....  :-)


 to write unless you go the other way and 
 want it to be efficient (ie string->enum is more complex then 
 enum->string).  Still both cases are pretty trivial to write in code.
 
 I guess the main thing going for it is that users would recognize the 
 pattern much more quickly (ie readability) although it does reduce the 
 chance of offset errors (had one of those just the other day).
 
 -Joel


Useful for bridging with scripting code. That's a good point.  Python 
has no enums either, so they sometimes get turned into strings when 
going into Python land.

Hey Kirk if you're listening, what does PyD do with enums?

--bb
Dec 03 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:

 Hey Kirk if you're listening, what does PyD do with enums?


Currently nothing. Python has no obvious analogue, so enums are not 
currently a convertible type. Enums and structs are high on the list of 
things I need to support.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Dec 04 2006
prev sibling parent reply janderson <askme me.com> writes:
Bill Baxter wrote:

 janderson wrote:

 Bill Baxter wrote:

 janderson wrote:

 It would be helpful if the following code would work:
     enum TestEnum {
         Value1, Value2
     }
     writefln("%s", TestEnum.Value2);




 I agree that I've wanted this kind of feature before too, but I don't
 want it at the expense of bloating every single library that contains
 enums with lots of string equivalents that will never get used in
 real code.  I.e. this kind of thing is really only useful for debug
 or prototype code.
 --bb


 I don't agree on this point (that it would only be used in debug).  As
 I said, in scripting  (ie game ai ect...) and in plugin libraries (ie
 maya) its common place to use a string lookup for enums.  The code
 isn't *much* longer or more bug pron


 Mmmm -- bug pr0n.  *much* longer ... more bug pr0n....  :-)


sorry I ment: slightly more bug prone but not much longer...

//enum -> string

enum A
{
   Value1,
...
};

string A[] =
{
   "Value1",
...
};


//string to enum

A AToString[char[]];

void register()
{
   AToString["Value1"] = Value;
   //ect...
}


Really not that much code.  Also a lot of times in C++ you register lots 
of things together...

struct AInfo
{
    string name;
    string discription;
    int cost;
};

string A[] =
{
   { "Value1", "Some value I picked", 10 },
...
};



 to write unless you go the other way and want it to be efficient (ie
 string->enum is more complex then enum->string).  Still both cases are
 pretty trivial to write in code.

 I guess the main thing going for it is that users would recognize the
 pattern much more quickly (ie readability) although it does reduce the
 chance of offset errors (had one of those just the other day).

 -Joel


 Useful for bridging with scripting code. That's a good point.  Python
 has no enums either, so they sometimes get turned into strings when
 going into Python land.

 Hey Kirk if you're listening, what does PyD do with enums?

 --bb
Dec 04 2006
parent janderson <askme me.com> writes:
janderson wrote:

 Bill Baxter wrote:
  > janderson wrote:
  >> Bill Baxter wrote:
  >>> janderson wrote:
  >>>>> It would be helpful if the following code would work:
  >>>>>     enum TestEnum {
  >>>>>         Value1, Value2
  >>>>>     }
  >>>>>     writefln("%s", TestEnum.Value2);
  >>>
  >>> I agree that I've wanted this kind of feature before too, but I don't
  >>> want it at the expense of bloating every single library that contains
  >>> enums with lots of string equivalents that will never get used in
  >>> real code.  I.e. this kind of thing is really only useful for debug
  >>> or prototype code.
  >>> --bb
  >>
  >> I don't agree on this point (that it would only be used in debug).  As
  >> I said, in scripting  (ie game ai ect...) and in plugin libraries (ie
  >> maya) its common place to use a string lookup for enums.  The code
  >> isn't *much* longer or more bug pron
  >
  > Mmmm -- bug pr0n.  *much* longer ... more bug pr0n....  :-)
 
 sorry I ment: slightly more bug prone but not much longer...
 
 //enum -> string
 
 enum A
 {
   Value1,
 ...
 };
 
 string A[] =
 {
   "Value1",
 ...
 };
 
 
 //string to enum
 
 A AToString[char[]];
 
 void register()
 {
   AToString["Value1"] = Value;
   //ect...
 }
 
 
 Really not that much code.  Also a lot of times in C++ you register lots 
 of things together...
 
 struct AInfo
 {
    string name;
    string discription;
    int cost;
 };
 
 string A[] =
 {
   { "Value1", "Some value I picked", 10 },
 ...
 };
 


For clarity that should be more like:

  AInfo A[] =
  {
    { "Value1", "Some value I picked", 10 },
  ...
  };



 
  >
  >> to write unless you go the other way and want it to be efficient (ie
  >> string->enum is more complex then enum->string).  Still both cases are
  >> pretty trivial to write in code.
  >>
  >> I guess the main thing going for it is that users would recognize the
  >> pattern much more quickly (ie readability) although it does reduce the
  >> chance of offset errors (had one of those just the other day).
  >>
  >> -Joel
  >
  > Useful for bridging with scripting code. That's a good point.  Python
  > has no enums either, so they sometimes get turned into strings when
  > going into Python land.
  >
  > Hey Kirk if you're listening, what does PyD do with enums?
  >
  > --bb
Dec 05 2006