On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun@gmail.com> wrote:

> something I may have actually used in real code writing a low-level networking library:

...
>

default template argument would sort that out wouldn't it?

On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw <ibuclaw@ubuntu.com> wrote:

> On 23 May 2013 14:52, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

>> Adding an initializer simply changes the default value from 0 to whatever
>> you want.  It's quite consistent IMO.
>>
>
> Don't think it makes sense in non-POD structs...
>
> Haven't tested, but is this an error?
>
> struct S
> {
>     const int;
>
>     this (int x)
>     {
>         this.x = x;    // here
>     }
> }
>
> S(5);

Well, since you didn't name the member, it didn't compile right off :)

But after I fixed that, it does compile, both on 2.061 and the beta.

However, there is definitely a bug somewhere, this compiles:

struct S
{
    const int x;
    int y;

    this (int x)
    {
        y = this.x;
        writeln(this.y);
        this.x = x;
        writeln(this.x);
        this.x = 0;
        writeln(this.x);
    }
}

outputs:
0
5
0

Seems like const qualifier for members is simply ignored inside the ctor, it should only be ignored until it is set, or until it is used.

-Steve

On Thu, May 23, 2013 at 4:57 PM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> Seems like const qualifier for members is simply ignored inside the ctor, it should only be ignored until it is set, or until it is used.
>

Is that perhaps to help with building strings, arrays etc...

On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:
> On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun@gmail.com> wrote:
>
>> something I may have actually used in real code writing a low-level
>> networking library:
>
> ...
>>
>
> default template argument would sort that out wouldn't it?

a) at the cost of unneeded template bloat
b) it requires to know your argument at compile-time. What if you packet construction is based on some text configuration file?

On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
> Seems like const qualifier for members is simply ignored inside the ctor, it should only be ignored until it is set, or until it is used.

I am quite sure I have seen it (mutability of immutable in constructor) guaranteed either by spec or TDPL. Don't have TDPL with me right now, need to check later.

On Thursday, 23 May 2013 at 09:35:03 UTC, Timothee Cour wrote:
> I wish dustmite could be improved to 'run the last mile' by attempting to
> merge files:
> a.d:
> import b;
> b.d:
> import c;
> c.d:
> //some stuff
>
> dustmite should attempt to merge such files and reduce to:
> a.d
> // some stuff

Added! https://github.com/CyberShadow/DustMite/commit/24ebc57858168c9fe4dea99e859ac6ccadab685c

It's been asked before, I think. It should work for simple cases (when the program can compile after all files' contents is moved into one single file). The obstacles with making it more flexible are that 1) to merge every pair of files, it would have to try N*(N-1) combinations; 2) it doesn't know which file is the "main" program file (the file which must be present for the test script to succeed), if there is one.

On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
> On Thu, 23 May 2013 10:16:13 -0400, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
>
>> On 23 May 2013 14:52, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>>> Adding an initializer simply changes the default value from 0 to whatever
>>> you want.  It's quite consistent IMO.
>>>
>>
>> Don't think it makes sense in non-POD structs...
>>
>> Haven't tested, but is this an error?
>>
>> struct S
>> {
>>    const int;
>>
>>    this (int x)
>>    {
>>        this.x = x;    // here
>>    }
>> }
>>
>> S(5);
>
> Well, since you didn't name the member, it didn't compile right off :)
>

Yeah... I've had little sleep so I'm not with it. =)

On Thu, 23 May 2013 11:07:16 -0400, Dicebot <m.strashun@gmail.com> wrote:

> On Thursday, 23 May 2013 at 14:58:01 UTC, Steven Schveighoffer wrote:
>> Seems like const qualifier for members is simply ignored inside the ctor, it should only be ignored until it is set, or until it is used.
>
> I am quite sure I have seen it (mutability of immutable in constructor) guaranteed either by spec or TDPL. Don't have TDPL with me right now, need to check later.

I did check, though not thoroughly.  I think it only talks about actual immutable constructors (that is, initializing a fully immutable-qualified instance).  It doesn't really talk about immutable members.

And for immutable constructors, the rule seems to be that you can assign fields as many times as you want, but you cannot read them, or call any methods.

I think whatever rules are used, they should be consistent for immutable/const members as well.

-Steve

On Thu, May 23, 2013 at 5:06 PM, Dicebot <m.strashun@gmail.com> wrote:

> On Thursday, 23 May 2013 at 14:56:14 UTC, Rory McGuire wrote:
>
>> On Thu, May 23, 2013 at 4:42 PM, Dicebot <m.strashun@gmail.com> wrote:
>>
> b) it requires to know your argument at compile-time. What if you packet construction is based on some text configuration file?
>

:) I'm sure we could think of something wrong with any part of the language if we really wanted to.

On Thursday, 23 May 2013 at 15:15:18 UTC, Rory McGuire wrote:
>> b) it requires to know your argument at compile-time. What if you packet
>> construction is based on some text configuration file?
>>
>
> :) I'm sure we could think of something wrong with any part of the language
> if we really wanted to.

Well, you see, I am not imagining it. Had to write a barebone traffic generation tool in C several months ago for project. It did almost exactly that, only with no help support from type system, of course.