On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>
> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

<repost in case the ether ate the last one>

just tried building a shared lib with

dmd -fPIC -defaultlib=phobos2so -shared {infiles} -of{outfile}

on ubuntu 12.10 64bit.

during link, it wants libphobos2so.so, but during run it wants libphobos2.so.0.63

On Friday, 24 May 2013 at 14:04:33 UTC, Dicebot wrote:
> On Friday, 24 May 2013 at 13:58:32 UTC, Steven Schveighoffer wrote:
>> Being able to dictate the .init data is very powerful and useful.  You can't remove that feature.
>
> Sure, I completely agree, thus the idea adding of CTFE-able constructor which will become the T.init for structs.
>
>> But the point I'm making is that the syntax IS consistent.  It just never worked before, because of the implicit 'static'
>
> No it is not. It never worked before because it was simply broken. Now it works properly from the point of spec, but it is inconsistent from the point of language design:
>
> int x = 5; // can you tell without looking at scope if it really initializes x or just defines .init for aggregate?
>
> Initializer syntax does not really make sense for non-static aggregate members at all, mutable or not.

They define a default value for the field. The constructor can override it. It is expected that a constructor is able to construct an object.

On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
>
> Join the dmd beta mailing list to keep up with the betas. This one is pretty much good to go, unless something disastrous crops up.
>
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

You can add that one :
http://d.puremagic.com/issues/show_bug.cgi?id=10166

Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076

On 5/23/2013 5:01 PM, Walter Bright wrote:
> On 5/23/2013 2:05 AM, Don wrote:
>> NO NO NO NO. I am violently opposed to this release.
>>
>> This beta contains the worst language misfeature of all time. It's silently
>> snuck in under the guise of a bugfix.
>
> Don has an excellent point. His case is bolstered by this causing Tango2 to fail
> to compile with error messages that have no obvious relationship with this change.
>
> Worse, as Don points out, this can result in silent breakage. Not everyone
> writes code that is 100% tested, and shipping code that no longer works would
> make someone justifiably very upset.
>
> The -transition=field detects such cases, but the user will not necessarily know
> to run it.
>
> So, I agree with Don. As it is, this is unacceptable, despite my agreement that
> it does make the language better. Therefore, I propose the following addition of
> a warning:
>
> ------------------------------
>     const int q = 5;
>
> Warning: const field with initializer should be static or enum.
> ------------------------------
>
> Over time, this can be upgraded to a deprecation and then an error.
>
> After a suitably long period of time as an error, then we can allow it with the
> new behavior.
>
>

On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
> Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076
>

So finally, what is the sate of things ?

On 5/26/2013 9:31 AM, deadalnix wrote:
> On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
>> Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076
>>
>
> So finally, what is the sate of things ?

Beta 7!


http://ftp.digitalmars.com/dmd2beta.zip

Remaining regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

On Saturday, 25 May 2013 at 05:32:28 UTC, deadalnix wrote:
> They define a default value for the field. The constructor can override it. It is expected that a constructor is able to construct an object.

Yes, I know. Actually, I have been saying it earlier in this topic. So what? :)

On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:
> On 5/26/2013 9:31 AM, deadalnix wrote:
>> On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
>>> Pull request to do this: https://github.com/D-Programming-Language/dmd/pull/2076
>>>
>>
>> So finally, what is the sate of things ?
>
> Beta 7!
>
>
> http://ftp.digitalmars.com/dmd2beta.zip
>
> Remaining regressions:
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

Sorry I was unclear. The question was about the chosen behavior for immutable/const initialization.

On 5/26/2013 8:05 PM, deadalnix wrote:
> On Sunday, 26 May 2013 at 18:52:11 UTC, Walter Bright wrote:
>> On 5/26/2013 9:31 AM, deadalnix wrote:
>>> On Saturday, 25 May 2013 at 21:07:26 UTC, Walter Bright wrote:
>>>> Pull request to do this:
>>>> https://github.com/D-Programming-Language/dmd/pull/2076
>>>>
>>>
>>> So finally, what is the sate of things ?
>>
>> Beta 7!
>>
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> Remaining regressions:
>>
>> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
>>
>
> Sorry I was unclear. The question was about the chosen behavior for
> immutable/const initialization.

I think the pull request answers that.

On Friday, 24 May 2013 at 13:54:21 UTC, Dicebot wrote:
> There is an option to prohibit initializers for struct member declarations at all and allow CTFE-able default constructors instead, but that would have been a major change.

I don't see a reason why we couldn't have both ways (1. member initializers and 2. CTFE-able default constructor) for defining the init state of structs. Probably the sensible thing would be to make all member initializers illegal iff a default constructor has been defined for a struct. I'd be interested in seeing a proper feature request discussion about this in a dedicated forum or at bugzilla.