Re: WTF! new in class is static?!?!
On Sunday, 10 June 2018 at 02:34:11 UTC, KingJoffrey wrote: On Sunday, 10 June 2018 at 01:27:50 UTC, bauss wrote: 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. Well then, you should like my idea for the dconf '2019' logo... Dman and a bug, holding hands, and the bug saying "I'm not a bug, I'm a feature!". Sure, because other compilers do not have bugs.
Re: WTF! new in class is static?!?!
On Sunday, 10 June 2018 at 01:27:50 UTC, bauss wrote: 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. Well then, you should like my idea for the dconf '2019' logo... Dman and a bug, holding hands, and the bug saying "I'm not a bug, I'm a feature!".
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
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
Re: WTF! new in class is static?!?!
On Saturday, 9 June 2018 at 13:49:48 UTC, 12345swordy wrote: No, because you been caught making imposter accounts left and right. Which btw we can tell as your poor attempts to imposter me. Well... why ya all r busy havin a go at me, the bugs remains (as do all D'other bugs).
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
But unlike you "king", Bauss isn't using tor to ban evade.
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
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)
}
---
Re: WTF! new in class is static?!?!
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
Re: WTF! new in class is static?!?!
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.
Re: WTF! new in class is static?!?!
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
Re: WTF! new in class is static?!?!
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!
-Steve
wait! everyone is saying it is a feature! So, which is it, a
feature or a bug?!?!?
Re: WTF! new in class is static?!?!
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]
Re: WTF! new in class is static?!?!
On 06/07/2018 11:26 PM, Ethan wrote:
The spec isn't clear on this but it uses the same rules as struct field
initialisation, ie it's defined once and copied to each instance on
creation.
https://dlang.org/spec/struct.html#default_struct_init
It says there that "The default initializers may not contain references
to mutable data."
DMD enforces that for pointers to primitives, but not for arrays, class
objects, or even pointers to structs:
struct S
{
int* p = new int(1); /* Error: cannot use non-constant CTFE pointer
in an initializer */
int[] a = [1, 2, 3]; /* no error */
C c = new C; /* no error */
S2* s = new S2; /* no error */
}
class C { int x = 4; }
struct S2 { int x = 5; }
Seems inconsistent to me.
Re: WTF! new in class is static?!?!
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!
-Steve
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote: I'm glad I finally found this out! This is not typical behavior in most languages is it? I don't think most languages allow this, and D used to not allow it either, but then CTFE got class support and it got enabled. If you understand how it works, it is sometimes useful... But, it is confusing for a *lot* of people so it might make sense to ban it again - or at least make it more obvious that this is what you intended when you write it.
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to something like
class B
{
A a;
this()
{
a = new A();
}
}
In C# it is different, can't remember if it is different in
C++. This has caused bugs in my code because the fields are all
pointing to the same data when I expected them to each have
unique data ;/
This method is error prone and the behavior should be reversed,
it should not break the majority of code. If one wants the
current behavior then static new could be used or something
else.
The spec looks pretty clear to me on that point
https://dlang.org/spec/class.html#field-init
Besides, defining behaviour at construction is what constructors
are for, I wouldn't expect anything outside a constructor to
happen when an object is constructed. So while I understand that
other languages may (successfully for them) do things differently
I don't think I'd like a breaking change for that.
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to something like
class B
{
A a;
this()
{
a = new A();
}
}
In C# it is different, can't remember if it is different in
C++. This has caused bugs in my code because the fields are all
pointing to the same data when I expected them to each have
unique data ;/
This method is error prone and the behavior should be reversed,
it should not break the majority of code. If one wants the
current behavior then static new could be used or something
else.
If you want a new one use a constructor call.
initalizers are support to be static, this only works because
ctfe supports newing classes.
Re: WTF! new in class is static?!?!
On Thursday, June 07, 2018 21:07:26 DigitalDesigns via Digitalmars-d-learn
wrote:
> class A;
>
> class B
> {
> A a = new A();
> }
>
> auto b1 = new B();
> auto b2 = new B();
>
> assert(b1.a == b2.a)!!
>
>
> I'm glad I finally found this out! This is not typical behavior
> in most languages is it?
>
> I'd expect it to be translated to something like
>
> class B
> {
> A a;
> this()
> {
> a = new A();
> }
> }
>
> In C# it is different, can't remember if it is different in C++.
> This has caused bugs in my code because the fields are all
> pointing to the same data when I expected them to each have
> unique data ;/
>
> This method is error prone and the behavior should be reversed,
> it should not break the majority of code. If one wants the
> current behavior then static new could be used or something else.
Well, if that compiles now with a non-immutable class object, then that was
a language improvement.
In any case, yes, the class object would be shared across all instances of
the class.
_Every_ type in D has an init value that they get default-initialized to
before the constructor is run (assuming that the type even has a
constructor). In the case of both classes and structs, whatever the member
variables are directly initialized with make up the init value. So, if you
have something like
struct S
{
int i = 42;
}
then every instance of S will start with the value of 42 for i, and if you
have something like
struct S
{
int i = 42;
this(int j)
{
i = j;
}
}
then S.i is 42 before the constructor is run and will then be whatever it
gets assigned to in the constructor after the constructor has run.
The situation with classes is exactly the same as structs except that you
don't have direct access to the init value (since you only ever deal with
class references, not the classes themselves). One key result of this is
that the class object is fully initialized to its init value for its exact
type before _any_ constructors are called, so you don't get that problem
that C++ has where the object isn't fully its correct type until all of the
constructors have been called (so calling virtual functions from a class
constructor in D actually works, unlike C++).
All of this is quite clean with value types, but in the case of member
variables that are pointers, dynamic arrays, or reference types that would
mean that if you had something like
struct S
{
int* ptr = new int(42);
}
every instance of S would have the same exact value for S.ptr, which can be
surprising and is why it's sometimes been suggested that it not be legal to
directly initialize member variables with mutable, non-value types. However,
historically, this really only mattered for dynamic arrays, because
originally it wasn't legal to directly initialize any member variable that
was a pointer or reference, because the compiler and runtime weren't
sophisticated enough to handle it. Several years ago, it was made possible
to directly initialize immutable class references, but that doesn't really
cause any problems, since sharing an immutable object doesn't cause
problems. However, if it's now possible for the init value of an object to
contain a mutable class reference or pointer, then the problem does get
worse, and arguably, it becomes more critical to just make it illegal in the
case of member variables in order to avoid the surprises (and bugs) that
come when folks misunderstand what it really means to directly initialize a
member variable in D.
In any case, the way that D works here is a direct result of how init values
work, and it really doesn't make sense for it to work any other way. At
most, it would make sense to simply make it illegal to directly initialize
types where it would be a problem.
- Jonathan M Davis
Re: WTF! new in class is static?!?!
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote: assert(b1.a == b2.a)!! The spec isn't clear on this but it uses the same rules as struct field initialisation, ie it's defined once and copied to each instance on creation. https://dlang.org/spec/struct.html#default_struct_init
WTF! new in class is static?!?!
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to something like
class B
{
A a;
this()
{
a = new A();
}
}
In C# it is different, can't remember if it is different in C++.
This has caused bugs in my code because the fields are all
pointing to the same data when I expected them to each have
unique data ;/
This method is error prone and the behavior should be reversed,
it should not break the majority of code. If one wants the
current behavior then static new could be used or something else.
