On Thursday, 9 February 2023 at 20:05:06 UTC, Ali Çehreli wrote:
Besides, D has zero problems with its private implementation in
the sense that there has been zero bugs related to it being
that way.
That is how a Python aficionado would defend the absence of
visibility attributes therein.
On Sunday, 27 December 2020 at 18:25:10 UTC, sighoya wrote:
This should work:
```
static assert(is(int == AliasSeq!int));
Drepl: static assert: `is(int == (int))` is false
```
That will only work for type tuples. We need a general solution
that would work for any alias tuple.
The most
Given a name bound to an alias sequence, what is a reliable way
to detect that?
import std.meta: AliasSeq;
alias a = AliasSeq!int;
static if () {
}
__traits(isSame, a, AliasSeq!a) could work but doesn't, because
it flattens singletons, which means __traits(isSame, int,
AliasSeq!int) is
On Tuesday, 10 November 2020 at 20:13:30 UTC, Daniel Kozak wrote:
non static nested function is a delegate, so you can just
assign it to delegate like I have posted or you can du this:
import std.stdio;
void main() {
void foo() {
writeln("It works as expected");
}
enum
On Tuesday, 10 November 2020 at 14:36:04 UTC, Steven
Schveighoffer wrote:
Is there a way to get a pointer to a non-static nested
function?
I don't think you can do it at compile time. You can at runtime
by accessing the funcptr of the delegate.
-Steve
Thanks for the reply. I will post
We can get the compile time equivalent of a member function's
address by applying '&' to the function in a static context:
struct S {
void foo() {}
}
enum pfoo = // ok
void main() {
// now we can use the pointer to create, for example, a
delegate
S s;
void delegate() dg;
On Thursday, 29 October 2020 at 16:45:51 UTC, Ali Çehreli wrote:
immutable string p;
shared static this() {
p = environment["PATH"]; // <-- Run time
}
Immutable static variables being implicitly non-thread-local is a
design mistake. Thread-local immutable variables have the same
right
On Friday, 10 July 2020 at 08:15:24 UTC, Max Samukha wrote:
a unfortunate
an unfortunate
On Thursday, 9 July 2020 at 21:04:57 UTC, Steven Schveighoffer
wrote:
Why isn't [] accepted as an empty AA literal?
Because it's an empty dynamic array literal.
If D were to accept an empty AA literal, I'd expect it to be
[:].
-Steve
Just as typeof(null) is a subtype of all nullable
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer
wrote:
Yes, that is correct.
-Steve
Why isn't [] accepted as an empty AA literal?
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
foo( [] ) doesn't
Should work in principle, but you can foo(null) to work around.
On Wednesday, 8 July 2020 at 20:11:05 UTC, IGotD- wrote:
Now since mySize is a template, shouldn't this work mySize!v,
but it doesn't? What essential understanding have I missed here?
You are trying to use a run-time value of v at compile-time,
which is not possible. If you want the
On Saturday, 30 May 2020 at 07:00:07 UTC, Mike Parker wrote:
I find it rather annoying, as I'm returning `const(char)*` and
not `char*`, but it is what it is. My question is, if I add
`return` to the function declarations, will this compile all
the way back to DMD 2.067 *without*
On Monday, 16 September 2019 at 13:13:50 UTC, Adam D. Ruppe wrote:
On Monday, 16 September 2019 at 07:02:04 UTC, Max Samukha wrote:
[...]
Well, sort of, your code is perfectly legal and has worked
since the beginning of D. The thing in the spec is referring to
the assumption the compiler
Please consider a project:
src/p2/
|---a.d
|---b.d
in which it is desirable that the logical package tree does not
fully correspond to the filesystem subtree:
src/p2/a.d:
module p1.p2.a;
...
src/p2/b.d:
module p1.p2.b;
import p1.p2.a;
...
dmd compiles the above structure
On Thursday, 12 September 2019 at 09:54:35 UTC, Ron Tarrant wrote:
I found this presented as a solution in a 2016 post:
On Wednesday, 15 June 2016 at 22:05:37 UTC, captaindet wrote:
enum myCSS = q{
GtkNotebook {
background-color: #e9e9e9;
}
GtkNotebook tab {
On Thursday, 12 September 2019 at 08:54:09 UTC, a11e99z wrote:
On Thursday, 12 September 2019 at 07:04:19 UTC, Max Samukha
wrote:
How to achieve the same for an array literal? The closest I
could come:
enum immutable(int[3]) _tmp = [1, 2, 3];
__gshared a = _tmp.ptr;
Is it possible to force
test.d:
__gshared t = "text".ptr;
As expected, the "text" literal ends up in a read-only data
segment, with a pointer to it stored in a writable data segment
(_TMP0 pointing into .rodata.str1.1):
.data segment
_D4test1tPya:
dd offset FLAT:_TMP0@64
db
On Sunday, 8 September 2019 at 10:04:57 UTC, Joel wrote:
I'm trying to understand delegates. Is there any good ways I
can get a better understanding of them?
You may want to read this:
https://tour.dlang.org/tour/en/basics/delegates
On Sunday, 8 September 2019 at 09:35:03 UTC, Jonathan M Davis
wrote:
The C++ support has been improved kind of piecemeal over time,
and initially, none of it was documented. So, it wasn't exactly
fully planned out when it was added. IIRC, it was added
originally so that the dmd frontend
On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis
wrote:
On Saturday, September 7, 2019 3:40:58 PM MDT Exil via
Digitalmars-d-learn wrote:
On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis
wrote:
> @safe:
> @system:
>
> then @system overrides @safe.
Just to add
extern(C++, "ns1"):
extern(C++, "ns2"): // Not in nested scope. Should it supersede?
void foo();
pragma(msg, foo.mangleof); // _ZN3ns13ns23fooEv instead of
expected _ZN3ns23fooEv
Is that by design?
extern(C++, "ns1") {
extern(C++, ns2) {
extern(C++, "ns3") {
extern(C++, ns4) {
void foo();
}
}
}
}
pragma(msg, foo.mangleof); // _ZN3ns23ns43ns13ns33fooEv
That
On Saturday, 7 September 2019 at 13:01:38 UTC, Jacob Carlborg
wrote:
On 2019-09-06 21:03, Max Samukha wrote:
Is there any practical use of having identically named .d and
.di alongside?
Same as in C/C++. This allows you to have a header file if you
want to distribute a closed source
On Friday, 6 September 2019 at 17:54:51 UTC, Adam D. Ruppe wrote:
On Friday, 6 September 2019 at 17:42:08 UTC, Max Samukha wrote:
That file was silently imported by the compiler (probably, a
bug).
That's by design - the automatic module import lookups actually
always look for .di file first,
On Friday, 6 September 2019 at 16:55:31 UTC, Max Samukha wrote:
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
If that is happening you hit a bug.
It seems unlikely though.
Could you elaborate a bit? How should extern(C/C++) definitions
be mangled - fully qualified or not,
On Friday, 6 September 2019 at 15:52:46 UTC, Stefan Koch wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When
On Friday, 6 September 2019 at 15:32:07 UTC, 0xEAB wrote:
On Friday, 6 September 2019 at 15:09:22 UTC, Max Samukha wrote:
Consider the following two modules:
What compiler version are you using?
DMD64 D Compiler v2.088.0-1-g4011382ea, linux
Consider the following two modules:
1. test.d:
module test;
import lib.a;
void main() {
foo();
}
2. lib/a.d:
module lib.a;
extern(C) void foo() {}
When compiled separately (dmd -c lib/a.d; dmd test.d a.o), the
function in 'a.o' is mangled as 'foo', but the reference in
'test.o' is
module lib.a;
class C {
this() {
}
void foo() {
}
~this() {
}
}
dmd -H -o- a.d:
// D import file generated from 'a.d'
module lib.a;
class C
{
this()
{
}
void foo();
~this();
}
The destructor and
module lib.a;
class C {
this() {
}
void foo() {
}
~this() {
}
}
dmd -H -o- a.d:
// D import file generated from 'a.d'
module lib.a;
class C
{
this()
{
}
void foo();
~this();
}
The destructor and
class A {
this(T = this)() {
static assert(is(T == B));
}
}
class B {
}
auto b = new B;
Here, T becomes A, which may be reasonable but is completely
useless. Is there a way to obtain the type of the class (or class
instance reference) the method is called on?
On Tuesday, 31 May 2016 at 11:54:40 UTC, Timon Gehr wrote:
On 30.05.2016 18:22, Max Samukha wrote:
From the spec (https://dlang.org/spec/function.html#nested):
"Nested
functions cannot be overloaded."
Anybody knows what's the rationale?
The rationale is that nobody has implemented it in
On Monday, 30 May 2016 at 23:17:15 UTC, pineapple wrote:
On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote:
From the spec (https://dlang.org/spec/function.html#nested):
"Nested functions cannot be overloaded."
Anybody knows what's the rationale?
I'm guessing it's related to -
From the spec (https://dlang.org/spec/function.html#nested):
"Nested functions cannot be overloaded."
Anybody knows what's the rationale?
On Sunday, 29 May 2016 at 11:03:36 UTC, Russel Winder wrote:
From what I can tell QtD is in need of effort or restarting.
I will probably give it another shot when D has better interop
with C++. Particularly, when multiple inheritance of C++
interfaces is implemented, Walter admits that
This code fails to compile:
void bar(alias f)() {
f();
}
void foo(alias f)() {
bar!f();
}
void main() {
void f()() {
}
foo!f();
}
Error: function test.main.f!().f is a nested function and cannot
be accessed from test.bar!(f).bar
But non-template nested functions are
On Tuesday, 26 April 2016 at 22:57:36 UTC, Jesse Phillips wrote:
typedef enum tagINSTALLMESSAGE
{
// 12 others ...
INSTALLMESSAGE_INITIALIZE ,
INSTALLMESSAGE_TERMINATE ,
INSTALLMESSAGE_SHOWDIALOG ,
#if (_WIN32_MSI >= 500)
INSTALLMESSAGE_PERFORMANCE
On Friday, 24 October 2014 at 08:53:05 UTC, Kagamin wrote:
maybe
template Foo(T a, T: T[U], U)
No luck. Error: undefined identifier T
On Friday, 24 October 2014 at 14:13:10 UTC, ketmar via
Digitalmars-d-learn wrote:
sorry if this is not what you mean, template magic sometimes
scares me
and i'm loosing my mind. ;-)
What I meant was your example with the delegate parameter moved
to the template list:
template Foo(T
On Friday, 24 October 2014 at 17:08:00 UTC, Max Samukha wrote:
Apparently, D doesn't allow type variables in value parameters
at all.
Nor does it allow passing delegates to value parameters, only
alias parameters.
If I remember correctly, at some point a syntax was introduced
for pattern-matching functions passed to templates. Something
like:
template Foo(B(A) foo, A, B)
{
}
alias f = Foo!((int x) = x % 2 == 0);
That would instantiate Foo with B == bool, A == int and foo bound
to the lambda.
The
On Thursday, 23 October 2014 at 11:25:01 UTC, Kagamin wrote:
Maybe, argument deduction?
template Foo(T: T[U], U)
{
...
}
Foo!(int[long]) // instantiates Foo with T set to int, U set
to long
Yes, but for a value template parameter.
template Foo(int[long] a);
{
}
Foo!([1: 2]); // ok,
43 matches
Mail list logo