May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 |
May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston Attachments:
| 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
|
May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston Attachments:
| 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.
|
May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | 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
|
May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 |
May 17, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Михаил Страшун | 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 |
May 26, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 |
May 26, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
Copyright © 1999-2021 by the D Language Foundation