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?
J
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
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
problem
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 ach
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 there
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, 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 some
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 `mustAddGCR
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
problem
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 th
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 `S
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 a
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
pragma
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, 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 Sty
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 encountered
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, typeof(S.tupleof
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 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 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 wit
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 t
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;` th
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;
On Thursday, May 10, 2018 03:23:50 Mike Franklin via Digitalmars-d-learn
wrote:
> My understanding is that nested structs have an implicit context
> pointer to their containing scope.
A non-static struct inside a function does, but I suspect that you're
thinking about non-static nested classes (w
On Thursday, 10 May 2018 at 06:22:37 UTC, Jonathan M Davis wrote:
Structs don't have that.
Should they?
On Thursday, May 10, 2018 06:31:09 Mike Franklin via Digitalmars-d-learn
wrote:
> On Thursday, 10 May 2018 at 06:22:37 UTC, Jonathan M Davis wrote:
> > Structs don't have that.
>
> Should they?
Honestly, I don't think that classes should have it, but changing it now
would break code (most notably
26 matches
Mail list logo
