I must resist the temptation to continue discussion about type system :) Should be a newsgroup topic created about it?

On Fri, May 17, 2013 at 12:02 PM, Don Clugston <dclugston@gmail.com> wrote:
>> What do you find unacceptable/inconvenient in "-transition=XXX" approach?
>
> Because 100% of existing cases must be changed.
>
> This isn't even like static variables becoming shared by default, where some
> of the cases needed to change to __gshared but the rest were OK with
> becoming shared.
> Every existing usage becomes a bug. There are no exceptions

But how it is different from marking it as an illegal? In one case you
get error messages, in other - the very same but optional error
messages. Am I missing something?
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

2013/5/17 Don Clugston <dclugston@gmail.com>
>
> > What do you find unacceptable/inconvenient in "-transition=XXX" approach?
>
> Because 100% of existing cases must be changed.
>
> This isn't even like static variables becoming shared by default, where
> some of the cases needed to change to __gshared but the rest were OK with
> becoming shared.
> Every existing usage becomes a bug. There are no exceptions.
>

In 2.063, some non-mutable field access were already changed to error.

struct S {
    immutable int x = 10;
}
enum y = S.x;  // 2.063 will cause "need 'this' for x" error.

At least in such cases, these are not silent breaking of existing code.

Kenji Hara

2013/5/17 Don Clugston <dclugston@gmail.com>

>
> > And what if you want to have BOTH default CTFE initialization and
> additional initialization based on some run-time data?
>
> Then you have a flaw in your thinking. That doesn't make sense.
> And, I still do not believe that there is a single valid use case for the
> new behaviour.
>
> Here's the reason:
> If you can provide an initializer for a struct member, that is the same
> for all instances of that struct, and you will never change that member, it
> shouldn't be a member of the struct in the first place. It should be static
> const or an enum value.
> If however you're going to change the member in the constructor, based on
> a runtime value, the initializer is meaningless and shouldn't have existed.
>

Actually the original idea (general, not const specific) makes sense: one may can  set correct type default value only at runtime, however it is not possible officially (you can but it is against the spec which mandates that default type value is fixed).

In such case a user does not care about CT initialization, only about runtime one, but CT happens in any case. The fact that D does not allow to reset default value of a struct at runtime is limiting because it forces to make (and later to ensure that) in each place where struct is used there is runtime initializer.

By the way, small, nitpick - master currently generates libphobos2.so
and branch 2.063 libphobos2so.so
Former is kind of better for aesthetics ;)
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/17/2013 12:54 AM, Don Clugston wrote:
> I think that the reason that having both an initializer and a constructor appears desirable, is actually as a workaround for the lack of struct default constructors.
> If we really need a solution for that, we should consider doing something like allowing struct default constructors, but requiring them to be CTFEable.
>

I know there's regular pressure to add default constructors, but I strongly oppose this. D has a lot of nice features because of the .init property. Default constructors wreck that.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/17/2013 5:21 AM, Михаил Страшун wrote:
> By the way, small, nitpick - master currently generates libphobos2.so
> and branch 2.063 libphobos2so.so
> Former is kind of better for aesthetics ;)
>

Oops, something on my end didn't get updated properly. Will fix.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/16/13 6:40 PM, Dmitry Olshansky wrote:
> 15-May-2013 09:05, Walter Bright пишет:
>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> I think it's time we officially started the beta process. Yes, I need
>> to start a 2.063 branch.
>
> I understand that Phobos bug fixes are lower priority.
> Still I believe we shouldn't ship it without at least
> these fixes reviewed and pulled in:
>
> Long standing bug 5524, std.algorithm remove with unstable policy
> (might need review but passes, been there for 3 months(!))
> https://github.com/D-Programming-Language/phobos/pull/1162

Could someone please review that at least now? Thanks.

> Bug in std.regex back-looper and consequently \b (reviewed, need
> somebody to merge):
> https://github.com/D-Programming-Language/phobos/pull/1273

Merged, perhaps it could be cherry-picked into 063 as well.

> And this one on BigInt (probably needs Don to take a look):
> https://github.com/D-Programming-Language/phobos/pull/1231

Merged, ditto.


Andrei

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

26-May-2013 10:36, Andrei Alexandrescu пишет:
> On 5/16/13 6:40 PM, Dmitry Olshansky wrote:
>> 15-May-2013 09:05, Walter Bright пишет:
>>> http://ftp.digitalmars.com/dmd2beta.zip
>>>
>>> I think it's time we officially started the beta process. Yes, I need
>>> to start a 2.063 branch.
>>
>> I understand that Phobos bug fixes are lower priority.
>> Still I believe we shouldn't ship it without at least
>> these fixes reviewed and pulled in:
>>
>> Long standing bug 5524, std.algorithm remove with unstable policy
>> (might need review but passes, been there for 3 months(!))
>> https://github.com/D-Programming-Language/phobos/pull/1162
>
> Could someone please review that at least now? Thanks.
>
Great, I'll give it a shot today but would welcome any help.


-- 
Dmitry Olshansky

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta