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