On Thursday, 10 May 2018 at 03:23:50 UTC, Mike Franklin wrote:
Consider the following code:
---
struct S
{
// intentionally not `static`
struct SS
{
int y() { return x; } // Error: need `this` for `x` of
type `int`
}
int x;
SS ss;
}
void main()
{
S s;
Consider the following code:
---
struct S
{
// intentionally not `static`
struct SS
{
int y() { return x; } // Error: need `this` for `x` of
type `int`
}
int x;
SS ss;
}
void main()
{
S s;
s.ss.y();
}
---
If I change `return x;` to `return this.x;`
On Wednesday, 9 May 2018 at 18:04:40 UTC, Per Nordlöw wrote:
On Wednesday, 9 May 2018 at 17:52:48 UTC, Meta wrote:
I wasn't able to reproduce it on dmd-nightly:
https://run.dlang.io/is/9wT8tH
What version of the compiler are you using?
Ahh, the struct needs to be in a unittest block for it
On Wednesday, 9 May 2018 at 15:20:12 UTC, Jonathan M Davis wrote:
On Wednesday, May 09, 2018 14:12:41 Dmitry Olshansky via
Digitalmars-d-learn wrote:
[...]
To an extent that's true, but anyone providing a library for
use by others in the D community should seriously consider
following it
On 08/05/2018 21:36, BoQsc wrote:
On Tuesday, 8 May 2018 at 19:19:26 UTC, Seb wrote:
On Tuesday, 8 May 2018 at 18:40:34 UTC, BoQsc wrote:
On Tuesday, 8 May 2018 at 18:38:10 UTC, BoQsc wrote:
On Tuesday, 8 May 2018 at 17:35:13 UTC, Jesse Phillips wrote:
[...]
Tested with these versions so
On Wednesday, 9 May 2018 at 17:52:48 UTC, Meta wrote:
I wasn't able to reproduce it on dmd-nightly:
https://run.dlang.io/is/9wT8tH
What version of the compiler are you using?
Ahh, the struct needs to be in a unittest block for it to happen:
struct R
{
@disable this(this);
int* _ptr;
On Wednesday, 9 May 2018 at 14:07:37 UTC, Per Nordlöw wrote:
Why (on earth) does
struct S
{
@disable this(this);
int* _ptr;
}
pragma(msg, typeof(S.tupleof));
prints
(int*, void*)
when
struct S
{
int* _ptr;
}
pragma(msg,
On Tuesday, May 08, 2018 16:18:40 Jesse Phillips via Digitalmars-d-learn
wrote:
> On Monday, 7 May 2018 at 22:24:25 UTC, Jonathan M Davis wrote:
> > I've been considering adding more configuration options where
> > you say something like you don't care if any invalid characters
> > are
On Wednesday, May 09, 2018 14:12:41 Dmitry Olshansky via Digitalmars-d-learn
wrote:
> On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc wrote:
> > The D Style suggest to camelCase constants, while Java naming
> > conventions always promoted uppercase letter.
> >
> > Is there an explanation why D
On Wednesday, 9 May 2018 at 14:36:38 UTC, Per Nordlöw wrote:
On Wednesday, 9 May 2018 at 14:34:02 UTC, Per Nordlöw wrote:
On Wednesday, 9 May 2018 at 14:20:41 UTC, Per Nordlöw wrote:
If so, we can temporarily modify the trait to exclude the
last `void*` member of the `S.tuple`. Given that it's
On Wednesday, 9 May 2018 at 14:34:02 UTC, Per Nordlöw wrote:
On Wednesday, 9 May 2018 at 14:20:41 UTC, Per Nordlöw wrote:
If so, we can temporarily modify the trait to exclude the last
`void*` member of the `S.tuple`. Given that it's always added
as the last member.
Also note that
On Wednesday, 9 May 2018 at 14:20:41 UTC, Per Nordlöw wrote:
If so, we can temporarily modify the trait to exclude the last
`void*` member of the `S.tuple`. Given that it's always added
as the last member.
Also note that
pragma(msg, __traits(isDisabled, S.this(this)));
fails to compile
On Wednesday, 9 May 2018 at 14:20:41 UTC, Per Nordlöw wrote:
If so, we can temporarily modify the trait to exclude the last
`void*` member of the `S.tuple`. Given that it's always added
as the last member.
Note that `std.traits.isCopyable!S` cannot be used, because it
will return true when
On Wednesday, 9 May 2018 at 14:07:37 UTC, Per Nordlöw wrote:
This prevents the trait `mustAddGCRangeOfStructOrUnion` [1]
from detecting when a container with manual memory management
doesn't have to be scanned by the GC as in, for instance,
enum NoGc;
struct S
{
@disable
On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc wrote:
The D Style suggest to camelCase constants, while Java naming
conventions always promoted uppercase letter.
Is there an explanation why D Style chose to use camelCase
instead of all UPPERCASE for constants, was there any technical
Why (on earth) does
struct S
{
@disable this(this);
int* _ptr;
}
pragma(msg, typeof(S.tupleof));
prints
(int*, void*)
when
struct S
{
int* _ptr;
}
pragma(msg, typeof(S.tupleof));
prints
(int*)
?!!!
This prevents the trait
On Wednesday, 9 May 2018 at 10:16:22 UTC, Melvin wrote:
I'm trying to find a friendly syntax for defining things in a
framework. For context, I've been looking into finding a
solution for this problem
(https://github.com/GodotNativeTools/godot-d/issues/1) on the
Godot-D project. I've done
On Wednesday, 9 May 2018 at 10:16:22 UTC, Melvin wrote:
class SomeNode : GodotScript!Node
{
@Signal void testSignal(float a, long b);
// The declaration above would trigger the generation of
this line
void testSignal(float a, long b) {
owner.emitSignal("testSignal", a, b); }
On Wednesday, May 09, 2018 09:38:14 BoQsc via Digitalmars-d-learn wrote:
> The D Style suggest to camelCase constants, while Java naming
> conventions always promoted uppercase letter.
>
> Is there an explanation why D Style chose to use camelCase
> instead of all UPPERCASE for constants, was
I'm trying to find a friendly syntax for defining things in a
framework. For context, I've been looking into finding a solution
for this problem
(https://github.com/GodotNativeTools/godot-d/issues/1) on the
Godot-D project. I've done some investigating already, and it
looks like I can only
On Wednesday, 9 May 2018 at 09:38:14 UTC, BoQsc wrote:
The D Style suggest to camelCase constants, while Java naming
conventions always promoted uppercase letter.
Is there an explanation why D Style chose to use camelCase
instead of all UPPERCASE for constants, was there any technical
On Wednesday, 9 May 2018 at 09:51:37 UTC, bauss wrote:
Just because.
To add on to this.
D is not Java, it's not C++, it's not C# etc.
D is D and D has its own conventions.
You're free to write your constants in all uppercase if you want.
I guess if I should come up with an actual reason
The D Style suggest to camelCase constants, while Java naming
conventions always promoted uppercase letter.
Is there an explanation why D Style chose to use camelCase
instead of all UPPERCASE for constants, was there any technical
problem that would appear while writing in all UPPERCASE?
23 matches
Mail list logo
