| |
 | Posted by Jonathan M Davis |  Permalink Reply |
|
Jonathan M Davis 
| http://d.puremagic.com/issues/show_bug.cgi?id=8817
Summary: Symbols named init should be illegal
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nobody@puremagic.com
ReportedBy: jmdavisProg@gmx.com
--- Comment #0 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-14 00:04:46 PDT ---
The fact that the compiler currently allows any symbols to be named init just causes problems. For instance, take this program:
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property static init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
The assertion in main fails, while the assertion in the constructor succeeds. That means that it's failing to actually override the init property for S (which is good), but now the init property for S is inaccessible. This is dangerous and will break all kinds of code. This sort of thing should just be disallowed. It gains us nothing and just causes problems. Similarly, this code
struct S
{
int i = 2;
this(int j)
{
assert(i == 2);
i = j;
}
@property S init()
{
return S(5);
}
}
void main()
{
assert(S.init == S(2));
}
results in this compilation error:
q.d(19): Error: need 'this' for init type @property S()
So, again, it makes it impossible to access the type's init property.
For some reason, TDPL (p. 275) specifically permits enums to declare min, max, and init properties, though it _does_ tell you that it's a bad idea to do so. So, if that's to be permitted, init would still have to be allowed there, but I'd strongly argue that that should be changed. And note that just like with structs, it causes weird issues:
enum MyEnum : int { a, b, c, init }
void main()
{
MyEnum e;
assert(e == MyEnum.a);
assert(MyEnum.init == MyEnum.a);
}
The first assertion passes but the second fails, meaning that once again, you can't get at the init property of the type anymore. Sure, declaring init as the first value fixes that, but init would be the first value anyway if init weren't explicitly declared. See issue# 8816.
The only situation where explicitly declaring init might make some sense would be to @disable it, but the syntax for disabling init is @disable this(); and not anything directly involving init. You can try and declare
struct S
{
int i;
@disable static S init;
}
void main()
{
S s;
}
but it compiles just fine.
At minimum, I would strongly argue that any and all symbols which could conflict with the actual init property for a type should be made illegal. There are a few cases where it may not cause problems (e.g. a local variable), but I'd argue that it would be cleaner to just disallow those as well. If need be, maybe init should become a keyword. Certainly, the current situation just permits bugs and the ability to declare symbols named init which conflict with the actual init property for a type needs to be eliminated.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
|
