On Monday, 17 May 2021 at 14:35:51 UTC, Steven Schveighoffer
wrote:
On 5/17/21 9:47 AM, jmh530 wrote:
The code below (simplified from my actual problem) generates a
warning that member function b "requires a dual-context, which
is deprecated".
However when I look at the list of deprecated
On Friday, 7 August 2020 at 21:03:47 UTC, aberba wrote:
Syntactically they look the same (although D's can do more
things) so I'm trying to understand how why in D it's called
template but in languages like C#/Java they're generics.
I guess I have fair understanding of D's code generation
On Wednesday, 10 June 2020 at 22:30:37 UTC, Vinod K Chandran
wrote:
On Wednesday, 10 June 2020 at 22:15:25 UTC, 12345swordy wrote:
It can't do binary operations and unary operations.
@12345swordy, You mean we can't do such ops inside the property
?
No, it means you can't do this:
e.x +=
On Wednesday, 10 June 2020 at 21:40:44 UTC, Paul Backus wrote:
On Wednesday, 10 June 2020 at 20:24:19 UTC, Vinod K Chandran
wrote:
Hi all,
I read in an old thread that authors of D wants to eliminate
@property. I just roughly read the big thread bu couldn't find
a conclusion. After all that
On Sunday, 15 March 2020 at 17:55:59 UTC, Steven Schveighoffer
wrote:
On 3/14/20 3:04 PM, 12345swordy wrote:
I.E.
switch (object)
case Type1 t1:
case Type2 t2:
case Type3 t3:
Is this a class object and you are trying to determine at
runtime which derived type it is and
On Saturday, 14 March 2020 at 20:52:30 UTC, aliak wrote:
On Saturday, 14 March 2020 at 19:04:28 UTC, 12345swordy wrote:
[...]
You can use the sumtype package
(https://code.dlang.org/packages/sumtype):
[...]
That simply to much verbiage.
I.E.
switch (object)
case Type1 t1:
case Type2 t2:
case Type3 t3:
On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
On Monday, 9 March 2020 at 10:09:56 UTC, Calvin P wrote:
@property exists so many years, Druntime & Phobos use it
2280 times. I can't believe it is not recommended.
They never implemented it right. This opCall type thing was THE
On Friday, 30 November 2018 at 15:32:55 UTC, 12345swordy wrote:
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote:
On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
[...]
[...]
100 % agree
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote:
On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a
segfault
What's the reasoning for
On Monday, 29 October 2018 at 00:16:38 UTC, Stanislav Blinov
wrote:
On Monday, 29 October 2018 at 00:01:21 UTC, DanielG wrote:
In my D app I'm declaring it this way:
extern (C) {
extern __gshared int myIntValue;
int myIntFunc (int a, int b);
}
The function seems to link OK,
On Wednesday, 25 July 2018 at 19:05:08 UTC, Guillaume Lathoud
wrote:
On Wednesday, 25 July 2018 at 04:46:20 UTC, rikki cattermole
wrote:
On 25/07/2018 5:32 AM, Guillaume Lathoud wrote:
Thanks for all the answers. I've just had a look at an
alternative: using dmd as a package. However that's a
On Tuesday, 24 July 2018 at 19:14:26 UTC, Vladimir Marchevsky
wrote:
On Tuesday, 24 July 2018 at 19:04:50 UTC, 12345swordy wrote:
Have you tried @disable ~this()?
Just tried:
1) no changes, still error about unresolved "QObject::`scalar
deleting destructor'(unsigned int)".
2) marking
On Tuesday, 24 July 2018 at 15:48:28 UTC, Vladimir Marchevsky
wrote:
After reading 2.081 patchnotes about improvements with binding
to cpp classes, I'm trying to test it - with simple examples
and Qt as cpp library.
[...]
Have you tried @disable ~this()?
Alexander
On Tuesday, 24 July 2018 at 05:27:36 UTC, rikki cattermole wrote:
On 24/07/2018 4:43 PM, Guillaume Lathoud wrote:
[...]
Doesn't exist.
Well, IMO it should exist as it can be quite useful for
generating metainfo.
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with profile-gc
and it allocated a lot there. Question is, why doesn't
On Friday, 22 June 2018 at 14:06:06 UTC, Flaze07 wrote:
recently, I visited the glossary and saw that functor exist in
D...I know that functor exist C++ as a way to easily allow
higher order function, but since D already has function and
delegates, is there a point to functor ?
It there for
On Saturday, 9 June 2018 at 13:49:48 UTC, 12345swordy wrote:
No, because you been caught making imposter accounts left and
right. Which btw we can tell as your poor attempts to imposter
me.
Well... why ya all r busy havin a go at me, the bugs remains (as
do all D'other bugs).
On Saturday, 9 June 2018 at 13:24:49 UTC, KingJoffrey wrote:
On Saturday, 9 June 2018 at 12:56:55 UTC, rikki cattermole
wrote:
But unlike you "king", Bauss isn't using tor to ban evade.
why you wanna ban little old me?
is it cause I made a crticism of D?
No, because you been caught making
On Saturday, 21 April 2018 at 02:08:24 UTC, solidstate1991 wrote:
In order to call a function multiple time at parallel
(rendering function, very well parallelizable), but in order to
push the CPU to it's limits I have to get some form of
parallelization. Currently I'm using parallel foreach,
On Wednesday, 10 January 2018 at 19:26:58 UTC, Adam D. Ruppe
wrote:
On Wednesday, 10 January 2018 at 19:07:46 UTC, 12345swordy
wrote:
I noticed, can't fix it cause it won't let me edit it.
OK, I'd just use foreach there anyway tho (then it actually
builds!).
But, hopefully once you get it
On Wednesday, 10 January 2018 at 18:45:17 UTC, Adam D. Ruppe
wrote:
On Wednesday, 10 January 2018 at 18:31:17 UTC, 12345swordy
wrote:
for(int x = 0; x < TL.length; x++)
{
auto b = [__traits(allMembers, TL[0])];
Simple mistake there...
I noticed, can't fix it cause it won't
I expect ["__ctor", "__dtor", "toString", "toHash", "opCmp",
"opEquals"], instead I got ["toString", "toHash", "opCmp",
"opEquals", "Monitor", "factory"]
Care anyone explain why it is?
Source is the following:
import std.stdio;
import std.traits;
interface A
{
}
class D : A
{
this()
On Thursday, 21 December 2017 at 06:50:44 UTC, Mike Parker wrote:
On Thursday, 21 December 2017 at 04:10:56 UTC, user1234 wrote:
[...]
[...]
[...]
The root of the problem is that in D, class destruction and
finalization are conflated. It would be much more accurate to
refer to ~this
import std.stdio;
class bob
{
}
class tom : bob
{
}
void main()
{
writeln(__traits(identifier,__traits(parent,tom)));
}
Am I doing this right? I am expecting it to print "bob".
On Monday, 4 September 2017 at 23:06:27 UTC, Nicholas Wilson
wrote:
On Monday, 4 September 2017 at 20:39:11 UTC, Igor wrote:
I found that I can't use __simd function from core.simd under
LDC
Correct LDC does not support the core.simd interface.
and that it has ldc.simd but I couldn't find
On Tuesday, 1 August 2017 at 16:20:07 UTC, Stefan Koch wrote:
On Tuesday, 1 August 2017 at 16:16:46 UTC, 12345swordy wrote:
I don't see this anywhere in the documentation. I am asking
this as I want to know that it's possible to create a
attribute to prevent certain functions being called in
I don't see this anywhere in the documentation. I am asking this
as I want to know that it's possible to create a attribute to
prevent certain functions being called in the body of a function.
To enforce a certain code standard upon myself.
28 matches
Mail list logo