Public outcry against new .init behaviour
Kristian Kilpi
kjkilpi at gmail.com
Mon Jul 2 14:32:53 PDT 2007
On Tue, 03 Jul 2007 00:20:39 +0300, Kristian Kilpi <kjkilpi at gmail.com>
wrote:
> On Mon, 02 Jul 2007 21:04:09 +0300, Walter Bright
> <newshound1 at digitalmars.com> wrote:
>
>> Deewiant wrote:
>>> It's not deadly - I found 14 instances of such in about 7000 LOC (wc
>>> -l), and
>>> they can be corrected - but it makes code noticeably uglier. This is
>>> one of
>>> those small, simple bits of syntactic sugar which make coding in D fun
>>> and
>>> productive. I want it back.
>>
>> I'll repost what I did earlier on this:
>>
>>> Andrei made an argument that if one had:
>>> struct S
>>> {
>>> static int foo;
>>> }
>>> S s = ...;
>>> assert(s.foo == S.foo);
>>> then, analogously:
>>> T t = ...;
>>> assert(t.init == T.init);
>>> should hold as well. Consistency is a strong argument.
>>
>>
>> I like the old behavior too, but with the increasing use of generic
>> code, I worry that the inconsistency is going to cause a lot of
>> problems in the future.
>
> I fail to see how this is a matter of consistency. To me, it's a matter
> of definition:
> 't.init' means the initialization value of the *variable* 't'.
> 'T.init' means the initialization value of the *type* 'T'.
>
> Now 't.init' is meaningless.
>
>
> Well, if one wants consistency ;) , lets consider the following:
>
> struct Z {
> static int x;
> int y;
> }
> Z a, b;
>
> Because 'a.x == b.x' holds, 'a.y == b.y' should hold too? <g>
Here is another (counter) example: ;)
't.init' did mean non-static init value (in old versions).
'T.init' means static init value.
Now 't.init == T.init' should hold.
So, 'a.y == a.x' should hold too?
'a.y' <-> 't.init' (non-static)
'a.x' <-> 'T.init' (static)
More information about the Digitalmars-d
mailing list