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
and C# and the slowness of Ruby and Python. I went online to look for a
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
While using C# the other day, I needed to know what enum value a variable was,
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.

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.

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

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.

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
> and C# and the slowness of Ruby and Python. I went online to look for a
> 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
> While using C# the other day, I needed to know what enum value a variable was,
> 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;

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

> 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

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

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

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