On Thursday, 29 October 2020 at 22:02:52 UTC, Paul Backus wrote:
I'm pretty sure the post you replied to is spam.
Yes, when I read the post again it is kind of hollow.
On Thursday, 29 October 2020 at 18:10:28 UTC, IGotD- wrote:
Is this what you are looking for?
https://dlang.org/phobos/std_container_dlist.html
I'm pretty sure the post you replied to is spam.
On Thursday, 29 October 2020 at 14:39:31 UTC, H. S. Teoh wrote:
On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer
via Digitalmars-d-learn wrote: [...]
D frequently allows no-op attributes.
[...]
I find that to be a bad smell in terms of language design,
actually. Either something
On Thursday, 29 October 2020 at 16:09:00 UTC, Adam D. Ruppe wrote:
The internal rt namespace is also on my website:
http://dpldocs.info/experimental-docs/rt.html
but of course that's private so you can't import it from user
code.
Thanks, that might be useful later :-).
On Thursday, 29 October 2020 at 16:09:10 UTC, kinke wrote:
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim
Grøstad wrote:
I meant the internals like vtable/typeinfo.
https://dlang.org/spec/abi.html#classes
Thanks!
On 10/29/20 10:16 AM, H. S. Teoh wrote:
> Module-level immutable can be initialized either as part of the
> declaration:
>
>immutable int x = 1;
To add, the expression can be a call to a function that need not return
immutable, as long as it is pure, which can be inferred by the compiler
f
On Thursday, 29 October 2020 at 18:06:55 UTC, xpaceeight wrote:
https://forum.dlang.org/post/bpixuevxzzltiybdr...@forum.dlang.org
It contains the data and a pointer to the next and previous
linked list node. This is given as follows. struct Node { int
data; struct Node *prev; struct Node *next
https://forum.dlang.org/post/bpixuevxzzltiybdr...@forum.dlang.org
It contains the data and a pointer to the next and previous
linked list node. This is given as follows. struct Node { int
data; struct Node *prev; struct Node *next; }; The function
insert() inserts the data into the beginning o
On Thursday, 29 October 2020 at 16:31:41 UTC, Ali Çehreli wrote:
On 10/28/20 5:55 PM, matheus wrote:
On Wednesday, 28 October 2020 at 22:07:06 UTC, H. S. Teoh
wrote:
... (This is why it's a bad idea to use enum with an array
literal, because every time it's referenced you get a new
copy of the
On Thu, Oct 29, 2020 at 04:56:46PM +, IGotD- via Digitalmars-d-learn wrote:
> On Thursday, 29 October 2020 at 16:45:51 UTC, Ali Çehreli wrote:
> >
> > import std;
> >
> > immutable string p;
> >
> > shared static this() {
> > p = environment["PATH"]; // <-- Run time
> > }
> >
>
> Just t
On Thursday, 29 October 2020 at 16:45:51 UTC, Ali Çehreli wrote:
import std;
immutable string p;
shared static this() {
p = environment["PATH"]; // <-- Run time
}
Just to clarify, immutable is allowed to be initialized in ctors
but not anything later than that? Moving p = environment["P
On 10/28/20 3:07 PM, H. S. Teoh wrote:
A shared immutable is initialized at compile-time,
To prevent a misunderstanding, immutable can be initialized at run time
as well. On the other hand, immutable initialized at compile time was
surprising to me when I learned it recently:
import std;
On 10/28/20 5:55 PM, matheus wrote:
On Wednesday, 28 October 2020 at 22:07:06 UTC, H. S. Teoh wrote:
... (This is why it's a bad idea to use enum with an array literal,
because every time it's referenced you get a new copy of the array.)
...
Could you please give an example (Snippet) about th
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim Grøstad
wrote:
I meant the internals like vtable/typeinfo.
https://dlang.org/spec/abi.html#classes
On Thursday, 29 October 2020 at 16:02:34 UTC, Ola Fosheim Grøstad:
That is the same as the class decl, I meant the internals like
vtable/typeinfo.
I don't know what you mean. typeinfo isn't a part of Object and
the vtable is built from those virtual methods.
If you mean the *module* object i
On Thursday, 29 October 2020 at 14:06:08 UTC, Adam D. Ruppe wrote:
On Thursday, 29 October 2020 at 14:03:46 UTC, Ola Fosheim
Grøstad wrote:
The class definition for Object in the runtime object.d is
"empty". Where can I find a description of the structure and
fields of "class Object"?
http://
On Thu, Oct 29, 2020 at 11:00:42AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 10/29/20 10:39 AM, H. S. Teoh wrote:
> > On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer via
> > Digitalmars-d-learn wrote:
> > [...]
> > > D frequently allows no-op attributes.
> > [
On 10/29/20 10:39 AM, H. S. Teoh wrote:
On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
D frequently allows no-op attributes.
[...]
I find that to be a bad smell in terms of language design, actually.
Either something should be allowed and h
On Thu, Oct 29, 2020 at 09:50:28AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> D frequently allows no-op attributes.
[...]
I find that to be a bad smell in terms of language design, actually.
Either something should be allowed and have a definite effect, or it
should not be
On Thursday, 29 October 2020 at 14:03:46 UTC, Ola Fosheim Grøstad
wrote:
The class definition for Object in the runtime object.d is
"empty". Where can I find a description of the structure and
fields of "class Object"?
http://dpldocs.info/experimental-docs/object.Object.html
The class definition for Object in the runtime object.d is
"empty". Where can I find a description of the structure and
fields of "class Object"?
On 10/28/20 6:28 PM, IGotD- wrote:
On Wednesday, 28 October 2020 at 21:54:19 UTC, Jan Hönig wrote:
shared immutable x = 1;
Is there a point to add shared to an immutable? Aren't immutable
implicitly also shared?
You are correct:
pragma(msg, typeof(x)); // immutable(int)
D frequently all
On Thu, Oct 29, 2020 at 08:13:42AM +, Jan Hönig via Digitalmars-d-learn
wrote:
[...]
> Is there some rule of thumb when to use what?
>
> I judge that using enum will slow down the compilation process, but
> might increase performance.
Nah. The slowdown is practically indiscernible. You should
On Thu, Oct 29, 2020 at 09:06:21AM +, Jan Hönig via Digitalmars-d-learn
wrote:
> On Thursday, 29 October 2020 at 09:01:12 UTC, Jan Hönig wrote:
> > This would mean, that this one should work as well.
>
> It does not work as I intended, as `() => {}` has not the return type
> of `void`.
>
> (
On Thursday, 29 October 2020 at 12:21:19 UTC, Ola Fosheim Grøstad
wrote:
You can test this with is(TYPE1==TYPE2)
is(shared(immutable(int))==immutable(int))
So I got that to true, which means that shared immutable is
exactly the same as immutable. Shared is implicit for immutable
which makes
On Thursday, 29 October 2020 at 08:13:42 UTC, Jan Hönig wrote:
Regarding the shared keyword, I am not sure if immutables are
shared per default. I thought they are not.
You can test this with is(TYPE1==TYPE2)
is(shared(immutable(int))==immutable(int))
On Thursday, 29 October 2020 at 09:06:21 UTC, Jan Hönig wrote:
On Thursday, 29 October 2020 at 09:01:12 UTC, Jan Hönig wrote:
This would mean, that this one should work as well.
It does not work as I intended, as `() => {}` has not the
return type of `void`.
(I don't know how to print: `Ret
On 29/10/2020 10:06 PM, Jan Hönig wrote:
On Thursday, 29 October 2020 at 09:01:12 UTC, Jan Hönig wrote:
This would mean, that this one should work as well.
It does not work as I intended, as `() => {}` has not the return type of
`void`.
(I don't know how to print: `ReturnType!(() => {})`)
On Thursday, 29 October 2020 at 09:01:12 UTC, Jan Hönig wrote:
This would mean, that this one should work as well.
It does not work as I intended, as `() => {}` has not the return
type of `void`.
(I don't know how to print: `ReturnType!(() => {})`)
On Thursday, 29 October 2020 at 08:48:59 UTC, rikki cattermole
wrote:
() => {}
Is actually:
() => Expression
Rule: ref|opt ParameterWithMemberAttributes => AssignExpression
https://dlang.org/spec/expression.html#lambdas
This would mean, that this one should work as well.
And you can![1]
I
On Wednesday, 28 October 2020 at 05:51:14 UTC, Nicholas Wilson
wrote:
but for a templated C this is tricker as I can't use a template
sequence parameter (...) unless C uses it in the same position
(I'm trying to generate a mangle from it so it needs to be
exact). Given
class A(T,int,args...
(Params){ FunctionBody; }
Rule: ref|opt ParameterWithMemberAttributes FunctionLiteralBody
https://dlang.org/spec/expression.html#function_literals
void function()
Is a type https://dlang.org/spec/type.html#delegates
() => {}
Is actually:
() => Expression
Rule: ref|opt ParameterWithMe
I have asked this on StackOverflow[1]. I have received a valid
answer, which solves my problem, however, I have still not
understood, why some versions of it work and some don't.
The code is here[2].
I don't understand why `a` compiles just fine, while `b` and `c`
don't.
I think, that I do
On Wednesday, 28 October 2020 at 22:07:06 UTC, H. S. Teoh wrote:
[...]
An enum only exists at compile-time, and does not occupy any
space. Each time it's referenced, a new instance of the value
is created. (This is why it's a bad idea to use enum with an
array literal, because every time it'
34 matches
Mail list logo
