Re: `this` and nested structs
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;
s.ss.y();
}
---
If I change `return x;` to `return this.x;` then of course it
emits the following error:
Error: no property `x` for type `SS`
My understanding is that `SS` should have a context pointer to
an instance of `S`, but how do I navigate the members of `S`
and `SS`. Is this a bug?
Thanks,
Mike
My understanding is that nested structs have an implicit
context pointer to their containing scope.
Nesting with hidden context pointer is only for nested structs
inside functions.
https://dlang.org/spec/struct.html#nested
This is a source a confusion unfortunately.
`this` and nested structs
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;` then of course it
emits the following error:
Error: no property `x` for type `SS`
My understanding is that `SS` should have a context pointer to an
instance of `S`, but how do I navigate the members of `S` and
`SS`. Is this a bug?
Thanks,
Mike
My understanding is that nested structs have an implicit context
pointer to their containing scope.
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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 to
happen:
struct R
{
@disable this(this);
int* _ptr;
}
unittest
{
struct S
{
@disable this(this);
int* _ptr;
}
struct T
{
int* _ptr;
}
pragma(msg, "R: ", typeof(R.tupleof));
pragma(msg, "S: ", typeof(S.tupleof));
pragma(msg, "T: ", typeof(T.tupleof));
}
prints
R: (int*)
S: (int*, void*)
T: (int*)
Why is that?
It's a context pointer to the enclosing function/object/struct.
Mark the struct as static to get rid of it.
Re: Why The D Style constants are written in camelCase?
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 with regards to public symbols so that they're consistent with how stuff is named across the ecosystem. It's not the end of the world to use a library that did something like use PascalCase instead of camelCase for its function names, or which used lowercase and underscores for its type names, or did any number of other things which are perfectly legitimate but don't follow the D style. However, they tend to throw people off when they don't follow the naming style of the rest of the ecosystem and generally cause friction when using 3rd party libraries. [...] If this issue https://github.com/dlang-community/dfmt/issues/227 is fixed we could potentially summarize that in .editorconfig file so that anyone who wishes can easily adopt it.
Re: "Start a Minimal web server" example do not work.
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 far, and had all the same errors: C:\Users\Vaidas>dmd --version DMD32 D Compiler v2.079.1 C:\Users\Vaidas>dub --version DUB version 1.8.1, built on Apr 14 2018 C:\Users\Vaidas>dmd --version DMD32 D Compiler v2.080.0 C:\Users\Vaidas>dub --version DUB version 1.9.0, built on May 1 2018 Linking... C:\D\dmd2\windows\bin\lld-link.exe: warning: eventcore.lib(sockets_106c_952.obj): undefined symbol: SetWindowLongPtrA C:\D\dmd2\windows\bin\lld-link.exe: warning: eventcore.lib(sockets_106c_952.obj): undefined symbol: GetWindowLongPtrA error: link failed Error: linker exited with status 1 C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1. Unfortunately, the MinGW version that the replacement libraries are built from omit this symbol. Please file a bug report. For Win32 (--arch=x86_mscoff) this symbol is aliased to SetWindowLongA which should be fine. That's with DMD's bundled LLD linker. Have you tried: 1) installing MS Visual Studio (as others have mentioned their linker works) 2) Using LDC (they usually ship a newer version of the LLD linker) I have installed the one suggested by the dmd-2.080.0.exe installer: Microsoft Visual Studio Community 2017 Version 15.7.0 VisualStudio.15.Release/15.7.0+27703.1 Microsoft .NET Framework Version 4.7.02556 What you actually need is Visual C++ (linker and runtime libraries). For the missing symbol above you also need the Windows SDK which is usually included in the Visual C++ installation.
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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;
}
unittest
{
struct S
{
@disable this(this);
int* _ptr;
}
struct T
{
int* _ptr;
}
pragma(msg, "R: ", typeof(R.tupleof));
pragma(msg, "S: ", typeof(S.tupleof));
pragma(msg, "T: ", typeof(T.tupleof));
}
prints
R: (int*)
S: (int*, void*)
T: (int*)
Why is that?
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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));
prints
(int*)
?!!!
I wasn't able to reproduce it on dmd-nightly:
https://run.dlang.io/is/9wT8tH
What version of the compiler are you using?
Re: dxml behavior after exception: continue parsing
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, in which case, you could cleanly parse past > > something like an unescaped &, but you'd then potentially be > > operating on invalid XML without knowing it and could get > > undesirable results depending on what exactly is wrong with the > > XML. I haven't decided for sure whether I'm going to add any > > such configuration options or how fine-grained they'd be, but > > either way, the current behavior will continue to be the > > default behavior. > > > > - Jonathan M Davis > > I'm not going to ask for that (configuration). I may look into > cloning dxml and changing it to parse the badly formed XML. Well, for the general case at least, being able to configure the parser to not care about certain types of validation is the best that I can think of at the moment for dealing with invalid XML (especially with the issues caused by the fact that only one range actually does the validation, making selective skipping of invalid stuff while parsing a very iffy proposition). dxml was designed with the idea that it would be operating on valid XML, and designing a parser to operate on invalid XML can get very tricky - to the point that it may simply be best for the programmer to design their own solution tailored to their particular use case if they're going to be encountering a lot of invalid XML. If all that's needed is to tell the parser to allow stuff like lone ampersands, then that's quite straightforward, but if you're dealing with anything more wrong than that, then things get hairy fast. It's those sorts of problems that have made html parsers so wildly inconsistent in what they do. Personally, I think that we'd have all been better off if the various protocols (particularly those related to the web) had always called for strict validation and rejected anything that didn't follow the spec. Instead, we've got this whole idea of "be strict in what you emit but relax in what you accept," and the result is that we've got a lot of incorrect implementations and a lot of invalid data floating around. And of course, if you don't accept something and someone else does, then your code is considered buggy even if it follows the protocol perfectly and the data is clearly invalid. So, in general, we're all kind of permanently screwed. :( If I can do reasonable things to make dxml better handle bad data, then I'm open to it, but given dxml's design, the options are somewhat limited, and it's just plain a hard problem in general. - Jonathan M Davis
Re: Why The D Style constants are written in camelCase?
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 Style chose to use camelCase > > instead of all UPPERCASE for constants, was there any technical > > problem that would appear while writing in all UPPERCASE? > > It is D style for standard library. It is mostly arbitrary but in > general sensible. > That’s it. To an extent that's true, but anyone providing a library for use by others in the D community should seriously consider following it with regards to public symbols so that they're consistent with how stuff is named across the ecosystem. It's not the end of the world to use a library that did something like use PascalCase instead of camelCase for its function names, or which used lowercase and underscores for its type names, or did any number of other things which are perfectly legitimate but don't follow the D style. However, they tend to throw people off when they don't follow the naming style of the rest of the ecosystem and generally cause friction when using 3rd party libraries. Stuff like how code is formatted or how internal symbols are named are completely irrelevant to that, but there's a reason that the D style guide provides naming conventions separately from saying anything about how Phobos code should look. The D ecosystem at large is better off if libraries in general follow the same naming conventions for their public symbols. Obviously, not everyone is going to choose to follow the official naming conventions, but IMHO, their use should be actively encouraged with regards to public symbols in libraries that are made publicly available. - Jonathan M Davis
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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 always
added as the last member.
Also note that
pragma(msg, __traits(isDisabled, S.this(this)));
fails to compile as
Error: identifier expected following `.`, not `this`
Ahh, but both
pragma(msg, __traits(isDisabled, S.__postblit));
pragma(msg, __traits(isDisabled, S.__xpostblit));
prints true for a struct with `@disable this(this);`
Which one should I pick to check if last element of `S.tupleof`
should be discarded?
Managed to put together the hack
private template mustAddGCRangeOfStructOrUnion(T)
if (is(T == struct) ||
is(T == union))
{
import std.traits : hasUDA;
import std.meta : anySatisfy;
static if (__traits(hasMember, T, "__postblit"))
{
static if (__traits(isDisabled, T.__postblit))
{
enum mustAddGCRangeOfStructOrUnion =
anySatisfy!(mustAddGCRangeOfMember, T.tupleof[0 .. $ - 1]);
}
else
{
enum mustAddGCRangeOfStructOrUnion =
anySatisfy!(mustAddGCRangeOfMember, T.tupleof);
}
}
else
{
enum mustAddGCRangeOfStructOrUnion =
anySatisfy!(mustAddGCRangeOfMember, T.tupleof);
}
}
defined here
https://github.com/nordlow/phobos-next/blob/master/src/gc_traits.d#L81
Destroy.
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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(msg, __traits(isDisabled, S.this(this))); fails to compile as Error: identifier expected following `.`, not `this` Ahh, but both pragma(msg, __traits(isDisabled, S.__postblit)); pragma(msg, __traits(isDisabled, S.__xpostblit)); prints true for a struct with `@disable this(this);` Which one should I pick to check if last element of `S.tupleof` should be discarded?
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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 as Error: identifier expected following `.`, not `this`
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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` has uncopyable members regardless of whether S.tupleof have any extra void* element or not (because of S's disabled postblit).
Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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 this(this); // disable S postlib
@NoGc int* _ptr;
}
static assert(!mustAddGCRangeOfStructOrUnion!S); // is
false when postblit of `S` is disabled
[1]
https://github.com/nordlow/phobos-next/blob/master/src/gc_traits.d#L81
Can we statically check if the postblit has been disabled via
@disable this(this);
?
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.
Re: Why The D Style constants are written in camelCase?
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 that would appear while writing in all UPPERCASE? It is D style for standard library. It is mostly arbitrary but in general sensible. That’s it.
Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait
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 `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 this(this); // disable S postlib
@NoGc int* _ptr;
}
static assert(!mustAddGCRangeOfStructOrUnion!S); // is false
when postblit of `S` is disabled
[1]
https://github.com/nordlow/phobos-next/blob/master/src/gc_traits.d#L81
Re: Generating a method using a UDA
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 investigating already, and it
looks like I can only achieve what I want with a mixin, but I'd
like to get a second opinion.
Say we have a class that defines a custom Signal (an event). In
an ideal world, the syntax would work similarly to this:
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); }
@Method emitTest()
{
testSignal(3.1415, 42);
}
}
The reason I want to use a UDA is to stay consistent with the
other UDAs already defined for Properties and Methods. It also
looks friendlier than using a mixin. Does anyone here have any
thoughts as to how this could work?
My main issue is injecting that generated method without
resorting to using a mixin. I was hoping that any code I needed
could be generated in the template that SomeNode inherits, but
that doesn't look possible because I can't inspect the subclass
(for good reason).
hi, i actually have something like that, which i should put on
github.
i used it to learn about D's introspection, so its more of a
prototype and will need some more work.
it looks like this:
class Test
{
mixin signalsOf!SigList;
interface SigList
{
@Signal void someFun(int);
}
void someFunHandler(int){}
}
signalsOf takes a type/template or function list, introspects
them then generates the actual signal functions.
the additional api is similar to qt's api.
void main()
{
Test t = new Test;
t.connect!"someFun"();
t.someFun(4); // emit the signal
t.disconnect!"someFun"();
}
you can have different connection types and i also have string
based connection and auto connection based on a naming convetion
like signalname: someSig and slotname: onSomeSig.
Re: Generating a method using a UDA
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); }
@Method emitTest()
{
testSignal(3.1415, 42);
}
}
The reason I want to use a UDA is to stay consistent with the
other UDAs already defined for Properties and Methods. It also
looks friendlier than using a mixin. Does anyone here have any
thoughts as to how this could work?
My main issue is injecting that generated method without
resorting to using a mixin. I was hoping that any code I needed
could be generated in the template that SomeNode inherits, but
that doesn't look possible because I can't inspect the subclass
(for good reason).
I'm afraid a mixin is the only real solution. You could also mark
testSignal as abstract, and have a template generate an
implementation class, but that would pollute every place where
you want to use a SomeNode, with something like SomeNode n =
implement!SomeNode();
--
Simen
Re: Why The D Style constants are written in camelCase?
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 any technical > problem that would appear while writing in all UPPERCASE? > > > > Java language references: > https://en.wikipedia.org/wiki/Naming_convention_(programming)#Java > https://www.javatpoint.com/java-naming-conventions > http://www.oracle.com/technetwork/java/codeconventions-135099.html > https://medium.com/modernnerd-code/java-for-humans-naming-conventions-6353 > a1cd21a1 > > > > D lang reference: > https://dlang.org/dstyle.html#naming_constants Every language makes its own choices with regards to how it goes about things, some of which are purely subjective. As I understand it, the idea of having constants being all uppercase comes from C, where it was done to avoid problems with the preprocessor. Typically, in C, macro names are in all uppercase so that symbols which aren't intended to involve macros don't end up with code being replaced by macros accidentally. Because constants in C are typically macros, the style of using all uppercase for constants has then gotten into some languages which are descendants of C, even if they don't have macros and don't have the same technical reasons as to why all uppercase would be desired (Java would be one such language). Ultimately, the fact that Java uses all uppercase letters for constants is a convention and not good or bad from a technical perspective. Ultimately, the reason that D does not follow that convention is that Andrei Alexandrescu didn't like it, and it's arguably a highly subjective choice, but there are reasons why it can matter. "Constants" are used so frequently in D and with so many different constructs (templates, enums, static const, etc.) that having them be all uppercase would have a tendancy to result in a _lot_ of symbols which were all uppercase. Code is often written in such a way that you don't have to care whether a symbol is an enum, a function, or a const/immutable static variable. e.g. in this code enum a = foo; foo has to be known at compile-time. However, foo could be a number of different kinds of symbols, and I don't necessarily care which it is. Right now, it could be another enum, but maybe tomorrow, it makes more sense for me to refactor my code so that it's a function. If I named enums in all caps, then I would have had enum A = FOO; and then when I changed FOO to a function, I would have had to have changed it to enum A = foo; By having the coding style make everything that could be used as a value be camelCase, you don't have to worry about changing the casing of symbol names just because the symbol was changed. You then only have to change the use of the symbol if the change to the symbol actually makes it act differently enough to require that the code be changed. If the code continues to work as-is, you don't have to change anything. Obviously, different kinds of symbols aren't always interchangeable, but the fact that they frequently are can be quite valuable and can reduce code maintenance, whereas having those kinds of symbols be named with different casing would just increase code maintenance. So, for D, using camelCase is advantageous from a code maintenance perspective, and I'd argue that the result is that using all uppercase for constants is just making your life harder for no real benefit. That's not true for Java, because Java has a lot fewer constructs, and they're rarely interchangeable. So, using all uppercase doesn't really cause any problems in Java, but D is not Java, so its situation is different. All that being said, you're obviously free to do whatever you want in your own code. I'd just ask that any public APIs that you make available in places like code.dlang.org follow the D naming conventions, because that will cause fewer problems for other people using your code. - Jonathan M Davis
Generating a method using a UDA
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 achieve what I want with a mixin, but I'd
like to get a second opinion.
Say we have a class that defines a custom Signal (an event). In
an ideal world, the syntax would work similarly to this:
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); }
@Method emitTest()
{
testSignal(3.1415, 42);
}
}
The reason I want to use a UDA is to stay consistent with the
other UDAs already defined for Properties and Methods. It also
looks friendlier than using a mixin. Does anyone here have any
thoughts as to how this could work?
My main issue is injecting that generated method without
resorting to using a mixin. I was hoping that any code I needed
could be generated in the template that SomeNode inherits, but
that doesn't look possible because I can't inspect the subclass
(for good reason).
Re: Why The D Style constants are written in camelCase?
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 that would appear while writing in all UPPERCASE? Java language references: https://en.wikipedia.org/wiki/Naming_convention_(programming)#Java https://www.javatpoint.com/java-naming-conventions http://www.oracle.com/technetwork/java/codeconventions-135099.html https://medium.com/modernnerd-code/java-for-humans-naming-conventions-6353a1cd21a1 D lang reference: https://dlang.org/dstyle.html#naming_constants Just because.
Re: Why The D Style constants are written in camelCase?
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 then it would be that constants are so common in D as not just constant values, but as "variables" to compile-time functions that are evaluated. Which is different from eg. Java where you only have constant values.
Why The D Style constants are written in camelCase?
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? Java language references: https://en.wikipedia.org/wiki/Naming_convention_(programming)#Java https://www.javatpoint.com/java-naming-conventions http://www.oracle.com/technetwork/java/codeconventions-135099.html https://medium.com/modernnerd-code/java-for-humans-naming-conventions-6353a1cd21a1 D lang reference: https://dlang.org/dstyle.html#naming_constants
