Furthermore:
https://issues.dlang.org/show_bug.cgi?id=3889
Shows real problems. You argue from the side that the bug already
exists so we must work around it because we can't go back and
"fix things". Who says? D has had breaking changes in the past so
it is not a deal breaker. It is also a
On Sunday, 20 May 2018 at 02:01:20 UTC, Alex wrote:
On Sunday, 20 May 2018 at 01:41:03 UTC, Dr.No wrote:
I'd like to pass a symbol as paramater (class static member0
and at same time get the type of this, something like this:
template myTemp(alias s)
{
enum myTemp =
On Sunday, 20 May 2018 at 02:09:47 UTC, Jonathan M Davis wrote:
On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via
Digitalmars-d- learn wrote:
Simply require == null as is null and be done with it.
That would be flat out wrong for dynamic arrays, because then
auto result = arr == null
On Sunday, May 20, 2018 01:51:50 IntegratedDimensions via Digitalmars-d-
learn wrote:
> Simply require == null as is null and be done with it.
That would be flat out wrong for dynamic arrays, because then
auto result = arr == null
and
int[] nullArr;
auto result = arr == nullArr;
would have
On Sunday, 20 May 2018 at 01:41:03 UTC, Dr.No wrote:
I'd like to pass a symbol as paramater (class static member0
and at same time get the type of this, something like this:
template myTemp(alias s)
{
enum myTemp = templateFunction!(??)(s.stringof);
}
the templateFunction has this
On Sunday, 20 May 2018 at 00:19:28 UTC, Jonathan M Davis wrote:
On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via
Digitalmars-d- learn wrote:
So, ultimately what I feels like is that you are actually
arguing for == null to be interpreted as is null but you don't
realize it yet.
Not
I'd like to pass a symbol as paramater (class static member0 and
at same time get the type of this, something like this:
template myTemp(alias s)
{
enum myTemp = templateFunction!(??)(s.stringof);
}
the templateFunction has this signature:
int templateFunction(T)(string
On Wednesday, 16 May 2018 at 18:56:26 UTC, Steven Schveighoffer
wrote:
On 5/16/18 2:45 PM, Dr.No wrote:
where is the actual source code implementation?
https://github.com/dlang/druntime/blob/7e3b4086fee8f2e2a6882942c677acc28df527ee/src/object.d#L3479
-Steve
thanks
On Saturday, May 19, 2018 17:13:36 Neia Neutuladh via Digitalmars-d-learn
wrote:
> I don't think I've ever wanted to distinguish a zero-length slice
> of an array from a null array.
It's safer if you don't, because it's so easy to end up with a dynamic array
that is empty instead of null, and
On Saturday, May 19, 2018 17:50:50 IntegratedDimensions via Digitalmars-d-
learn wrote:
> So, ultimately what I feels like is that you are actually arguing
> for == null to be interpreted as is null but you don't realize it
> yet.
Not really, no. Having
foo == null
be rewritten to
foo is null
I have a member callback that I want to use as a C callback.
This is impossible due to the `hidden this` passed as the "first"
parameter.
The callback already makes it's last value a user pointer which I
use as a "this".
If I make my method static extern(C) then there is no crash and
On Saturday, 19 May 2018 at 18:19:35 UTC, IntegratedDimensions
wrote:
Is there any way to create an int24 type that behaves just like
any other built in type without having to reimplement
everything?
In fact, what I'd like to do is create an arbitrary type:
struct atype(T)
{
}
where
Is there any way to create an int24 type that behaves just like
any other built in type without having to reimplement everything?
On Saturday, 19 May 2018 at 01:31:38 UTC, Jonathan M Davis wrote:
On Friday, May 18, 2018 23:53:12 IntegratedDimensions via
Digitalmars-d- learn wrote:
Why does D complain when using == to compare with null? Is
there really any technical reason? if one just defines == null
to is null then
On Saturday, 19 May 2018 at 17:33:08 UTC, Robert M. Münch wrote:
On 2018-05-18 14:42:17 +, Adam D. Ruppe said:
A value struct return is actually done via a hidden pointer
parameter (so the function can construct it in-place for the
caller, a standard optimization), so it just shifted all
On 2018-05-18 14:42:17 +, Adam D. Ruppe said:
On Friday, 18 May 2018 at 14:06:11 UTC, Robert M. Münch wrote:
So, having a wrong return-type here, resulted in the const char *text
parameter always being NULL. Not sure I understand the relation but
looks strange to me... at least not very
On Saturday, 19 May 2018 at 04:30:24 UTC, Jonathan M Davis wrote:
On Saturday, May 19, 2018 03:32:53 Neia Neutuladh via
Digitalmars-d-learn wrote:
> Of course, the most notable case where using == with null is
> a terrible idea is dynamic arrays, and that's the case where
> the compiler
17 matches
Mail list logo
