June 07, 2018
On 6/7/18 6:58 PM, DigitalDesigns wrote:
> On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer wrote:
>> On 6/7/18 5:07 PM, DigitalDesigns wrote:
>>> class A;
>>>
>>> class B
>>> {
>>>     A a = new A();
>>> }
>>>
>>> auto b1 = new B();
>>> auto b2 = new B();
>>>
>>> assert(b1.a == b2.a)!!
>>
>> Yep, long-standing issue: https://issues.dlang.org/show_bug.cgi?id=2947
>>
>> Almost a decade old!
>>
> 
> wait! everyone is saying it is a feature! So, which is it, a feature or a bug?!?!?

It's a feature that you can assign a static initializer to a class or struct member and have that work at compile time (using CTFE).

But when it's a reference to mutable data, it's a bug. Just the idea that you have implicitly shared data if you create instances in multiple threads should make it obviously a bug.

Even back then it was a debate, look at the bug report. But it's definitely a bug. Just hard to close since it will probably break a lot of code.

-Steve
June 07, 2018
On Thursday, 7 June 2018 at 23:08:22 UTC, Steven Schveighoffer wrote:
> On 6/7/18 6:58 PM, DigitalDesigns wrote:
>> On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer wrote:
>>> On 6/7/18 5:07 PM, DigitalDesigns wrote:
>>>> class A;
>>>>
>>>> class B
>>>> {
>>>>     A a = new A();
>>>> }
>>>>
>>>> auto b1 = new B();
>>>> auto b2 = new B();
>>>>
>>>> assert(b1.a == b2.a)!!
>>>
>>> Yep, long-standing issue: https://issues.dlang.org/show_bug.cgi?id=2947
>>>
>>> Almost a decade old!
>>>
>> 
>> wait! everyone is saying it is a feature! So, which is it, a feature or a bug?!?!?
>
> It's a feature that you can assign a static initializer to a class or struct member and have that work at compile time (using CTFE).
>
> But when it's a reference to mutable data, it's a bug. Just the idea that you have implicitly shared data if you create instances in multiple threads should make it obviously a bug.
>
> Even back then it was a debate, look at the bug report. But it's definitely a bug. Just hard to close since it will probably break a lot of code.
>
> -Steve

I would expect that using a static initialize would not break as much code going from immutable to mutable than the other way around. Someone should have been smart enough to create a static new so both methods could have been implemented in a sane way.
June 08, 2018
On Thursday, June 07, 2018 22:43:50 aliak via Digitalmars-d-learn wrote:
> On Thursday, 7 June 2018 at 21:32:54 UTC, Jonathan M Davis wrote:
> > struct S
> > {
> >
> >     int* ptr = new int(42);
> >
> > }
>
> Is that supposed to compile? -> https://run.dlang.io/is/SjUEOu
>
> Error: cannot use non-constant CTFE pointer in an initializer &[42][0]

Not necessarily. It's the pointer equivalent of what the OP did with a mutable class reference, and I was using it for demonstrative purposes. The mutable class reference case didn't used to compile (it used to have to be immutable). This example is just the logic of what happens if it's legal with pointers too. If it hasn't been changed to be legal with pointers like it has been with classes, then that's arguably a good thing.

- Jonathan M Davis

June 09, 2018
On Saturday, 9 June 2018 at 09:24:48 UTC, KingJoffrey wrote:
> On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer wrote:
>>
>> Yep, long-standing issue: https://issues.dlang.org/show_bug.cgi?id=2947
>>
>> Almost a decade old!
>>
>> -Steve
>
> Another reason why I still refuse to bring my code to D.
>
> As if the module not respecting class encapsulation was not enough (see my rants about it elsewhere), D even allows two class instances to share non static mutable data!!
>
> wtf!
>
> --------------
> import std.stdio;
>
> class A
> {
>     int[] c = [3,3];
> }
>
> void main()
> {
>     A ca = new A;
>     A cb = new A;
>
>     ca.c[0] = 44;
>
>     writeln(cb.c[0]);
>     // prints 44!!!! (in C++, Java and C#, this would - correctly - print 3)
> }
> ---------------

Nobody cares about your opinion.

Nobody is forcing you to write code like that.

In fact most programs will be written without such code, for good reason.

Regardless if it does the "correct" thing or not.
June 09, 2018
On Saturday, 9 June 2018 at 11:47:54 UTC, bauss wrote:
>
> Nobody cares about your opinion.
>
> Nobody is forcing you to write code like that.
>
> In fact most programs will be written without such code, for good reason.
>
> Regardless if it does the "correct" thing or not.

Dude. That response is so childish. Don't speak to people like that.

And given that no mainstream compiler would allow you to share mutable data like that, maybe you and others in the D 'community' should start paying attention to the 'opinions' of those who do professional development with professional compilers.

June 10, 2018
But unlike you "king", Bauss isn't using tor to ban evade.

June 09, 2018
On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote:
> But unlike you "king", Bauss isn't using tor to ban evade.

why you wanna ban little old me?

is it cause I made a crticism of D?

did i hurt your feelings?

..and everyone I know uses tor - and you should too - whether you're evading something or not - otherwise tor has no value - cause sites will just block tor - and then all those people that use tor for advancing human rights around the world, will lose the platform they need to do that, without being persecuted, cause they criticised something.


June 09, 2018
On Saturday, 9 June 2018 at 13:24:49 UTC, KingJoffrey wrote:
> On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole wrote:
>> But unlike you "king", Bauss isn't using tor to ban evade.
>
> why you wanna ban little old me?
>
> is it cause I made a crticism of D?

No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me.
June 09, 2018
On Friday, 8 June 2018 at 18:18:27 UTC, Jonathan M Davis wrote:
> On Thursday, June 07, 2018 22:43:50 aliak via Digitalmars-d-learn wrote:
>> On Thursday, 7 June 2018 at 21:32:54 UTC, Jonathan M Davis wrote:
>> > [...]
>>
>> Is that supposed to compile? -> https://run.dlang.io/is/SjUEOu
>>
>> Error: cannot use non-constant CTFE pointer in an initializer &[42][0]
>
> Not necessarily. It's the pointer equivalent of what the OP did with a mutable class reference, and I was using it for demonstrative purposes. The mutable class reference case didn't used to compile (it used to have to be immutable). This example is just the logic of what happens if it's legal with pointers too. If it hasn't been changed to be legal with pointers like it has been with classes, then that's arguably a good thing.
>
> - Jonathan M Davis

Boh, it seems it actually has, just not with primitive types it seems:

struct A {
  	int i = 3;
}

struct B {
  	auto a = new A(3);
}


Above compile fine :o

June 10, 2018
On Saturday, 9 June 2018 at 12:40:07 UTC, RealProgrammer wrote:
> maybe you and others in the D 'community' should start paying attention to the 'opinions' of those who do professional development with professional compilers.

I do professional work with a professional compiler aka. The D compiler and I've been doing so for years.