Alexander Panek wrote:
> Robert Fraser wrote:
>> Constant initialization can already be paired with declaration for non-class types:
>>
>> const(int) HTTP_PORT = 80;
>>
>> But it can't be for class types at global scope:
>>
>> const(Port) HTTP_PORT = new Port(80);
>>
>>
>> How is making it valid for (primitives, arrays, structs, anything with a constant initializer) but not for classes "keeping initialization in one place"?
> 
> You're having a compile-time literal vs. a runtime object here. That's kinda a big difference, you know? I wouldn't want to have my runtime object initialization to be somewhere in class declaration scope. Kinda hard to measure the performance then.
> 
> Oh, besides... this wouldn't even be in static constructor, but rather the normal constructor.
> 
> class A {
>     Port httpPort;
> 
>     this (int port = 80) {
>         httpPort = new Port(port);
>     }
> }
> 
> I'd like to keep the "verbosity" of initializing class members at runtime as-is.

You don't need a class for that, as you probably know. What I want is for:

const(Port) HTTP_PORT = new Port(80);

to be equivalent to:

Port HTTP_PORT;
static this() { HTTP_PORT = new Port(80); }

except, you know, allowing the const in there somewhere.

On Sun, 24 Feb 2008 00:19:59 +0100, Robert Fraser <fraserofthenight@gmail.com> wrote:

> Alexander Panek wrote:
>> Robert Fraser wrote:
>>> Constant initialization can already be paired with declaration for non-class types:
>>>
>>> const(int) HTTP_PORT = 80;
>>>
>>> But it can't be for class types at global scope:
>>>
>>> const(Port) HTTP_PORT = new Port(80);
>>>
>>>
>>> How is making it valid for (primitives, arrays, structs, anything with a constant initializer) but not for classes "keeping initialization in one place"?
>>  You're having a compile-time literal vs. a runtime object here. That's kinda a big difference, you know? I wouldn't want to have my runtime object initialization to be somewhere in class declaration scope. Kinda hard to measure the performance then.
>>  Oh, besides... this wouldn't even be in static constructor, but rather the normal constructor.
>>  class A {
>>     Port httpPort;
>>      this (int port = 80) {
>>         httpPort = new Port(port);
>>     }
>> }
>>  I'd like to keep the "verbosity" of initializing class members at runtime as-is.
>
> You don't need a class for that, as you probably know. What I want is for:
>
> const(Port) HTTP_PORT = new Port(80);
>
> to be equivalent to:
>
> Port HTTP_PORT;
> static this() { HTTP_PORT = new Port(80); }
>
> except, you know, allowing the const in there somewhere.


Something like this was mentioned a few months back. That any compile-time initialization the compiler wasn't able to do at compile time, should be automagically moved to a static this. I don't remember what Walter said about it, though.
IMO it sounds like a nice feature, but one that should show a warning.

dominik wrote:
> for example, though this might've been solved for D2 already:
> 
> char[][int] foo = [1:"barbar", 2:"bar"]; - this won't work with dmd compiler,
> 
> but this will:
> 
> char[][int] foo = [1:"barbar"[], 2:"bar"];
> 

Agreed. Initializers' type deductions should automatically use the most specialized type that can accomodate all the values.
Same thing for delegate/function literal return-type deductions.
so ["foo", "bar"] should be char[3][2], as currently, but ["foo", "barf"] should use char[][2] automatically, (int i) { if (i) return 2; else return 3f; } should be float delegate(int).

That falls under "small stuff that adds to language polish". And language polish, in the long run, is probably more important than groundbreaking features.

Please think about it. :)

 --downs

downs:
> so ["foo", "bar"] should be char[3][2], as currently, but ["foo", "barf"] should use char[][2] automatically,

Too much automatic things may lead to problems. I don't like that too much. I'd like a more systematic (uniform) behavior there (for example: "always create dynamic array when not explicitly specified otherwise").

Bye,
bearophile

On Thu, 28 Feb 2008, bearophile wrote:

> downs:
>> so ["foo", "bar"] should be char[3][2], as currently, but ["foo", "barf"] should use
>> char[][2] automatically,
>
> Too much automatic things may lead to problems. I don't like that too much.
> I'd like a more systematic (uniform) behavior there (for example:
> "always create dynamic array when not explicitly specified otherwise").

Having the most general case as default is easier to remember. But if one writes:

  char[3][2] foo = [ "foo", "bar" ];

it should still be able to unify the types. Having the opposite as default is annoying since it can lead to subtle bugs. I once had an array of strings that worked just fine with Stdout() (in tango), but FilePath couldn't find the file. Even strace couldn't reveal the bug. But adding missing []s fixed it.

>
> Bye,
> bearophile
>