alias char[] string

This really needs to be added. Right now people do it in their own code, but unless the alias is marked private (easy to forget), it will eventually conflict and you have to fully qualify the name.

having to type 'my.longnamedmodule.string' makes it useless.

also by making it private you essentially have to do it in every single module.

Please add these to object.d ASAP

Neither Sean nor I are comfortable about this macro. It adds a keyword to the language, though not a real keyword, which seems kinda bogus when Walter is trying to keep the keyword list short. We need to think about it some more, so all I can offer for now are my apologies that it may take some time to resolve

If not for all cases, I think this should at least be defined in a version(PhobosCompatibility?) block.

Otherwise Tangobos does not really make it possible to compile most Phobos code without modifying the source code.

In fact, if Tangobos is to work properly, then the entire contents of Tangobos' std.compat should be included in tango in a version(PhobosCompatibility?) block in Tango's object.di or equivalent.

For reference, those contents are:

extern (C) int printf(char *, ...);

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

alias Exception Error;
alias bool      bit;

Actually I could live without the bool-bit thing, since that's deprecated. But using 'string' instead of 'char[]' is actually pushed by Walter as being the preferred style for writing code these days. So you can expect that a lot of Phobos code will be using it.

Or, rather than putting those aliases directly in object.di, maybe this would be better:

version(PhobosCompatibility) { public import std.compat; }

Gah, printf!

Another reason for string and friends being problematic; They were added to D 2.0 as the invariant string definitions, and then in D 1.0 for compatibility. But the semantics for a D 1.0 string is very very different from a D 2.0 string, not really making code portable between the two versions at all.

See also #902.

I think code have to be ported from D1 to D2 anyway at some point in the future. In many cases the D2 meaning is favourable.

It is likely that the compiler will give proper errors if the semantics won't fit.

Maybe the D2-Tango ppl have experience with this they want to share? :P

It depends somewhat on what becomes implicitly convertible to what, but at least I have doubts about very much invariant use in Tango.

You have to make a decision on this, people.

If it's not going to happen you need to close this wontfix ASAP so people know that everyone is to be responsible for working around this incompatibility for themselves.

If it is going to happen you need to do it ASAP so people can start using it and stop creating their own workarounds.

Won't be resolved in 99.5

Replying to lindquist:

This really needs to be added. Right now people do it in their own code, but unless the alias is marked private (easy to forget), it will eventually conflict and you have to fully qualify the name.

This might be a compiler bug, but last time i tried (dmd 1.028 and 1.027) private aliases also conflicted.

file main.d

import test;
import test2;

void main(string[]) {}

file test.d

module test;

private alias char[] string;

file test2.d

module test2;

private alias char[] string;

dmd main.d test.d test2.d output:

main.d(4): Error: test.string at test.d(3) conflicts with test2.string at test2.d(3)

When libraries want to be D2 compatible they are going to use the string alias. If someone whould use more than one library witch defines a alias for string, they will run into the problem with the string alias. This problem won't exist if Tango includes a string alias because then there will only be one library with the alias.

#558 marked as a duplicate of this.