On the main forum, Paul Backus proposed a nested function as well as a
scoped lock.
On 8/26/22 10:13, mw wrote:
>Object lock = (a particular condition) ? realLock : null;
And I want to point out that "a particular condition" must not change
between the check above and
Hi,
I haven't tried, but can I do:
```
void foo(lots of params) {
Object lock = (a particular condition) ? realLock : null;
synchronized(lock) {
// lots of complex code block here
}
}
```
i.e depending on a a particular condition, the complex code block
either need to be sync
On Wednesday, 20 July 2022 at 13:35:14 UTC, Kagamin wrote:
On Tuesday, 19 July 2022 at 18:05:34 UTC, Antonio wrote:
In a relational database, `NULL` is not the same that `""`...
and `NULL` is not the same that `0`. Are semantically
different and there are database invariants (li
On Tuesday, 19 July 2022 at 18:05:34 UTC, Antonio wrote:
In a relational database, `NULL` is not the same that `""`...
and `NULL` is not the same that `0`. Are semantically
different and there are database invariants (like foreign keys)
based on it. Trying to "mix
On Tuesday, 19 July 2022 at 16:55:39 UTC, Kagamin wrote:
As I understand, in your scenario there's no difference between
null string and empty string, they both work like empty string,
and D treats them as empty string. That's what I mean when I
said that distinction between null and empty
On Tuesday, 19 July 2022 at 17:05:27 UTC, Kagamin wrote:
Also what's the difference between null and empty phone number?
In a relational database, `NULL` is not the same that `""`... and
`NULL` is not the same that `0`. Are semantically different and
there are database invari
Also what's the difference between null and empty phone number?
On Tuesday, 19 July 2022 at 10:29:40 UTC, Antonio wrote:
The summary is that a DTO that works like a Map needs to
represent the absent key ant this is not the same that the Null
value
Example:
```d
struct Null { /*...*/ }
struct Undefined { /*...*/ }
struct ContactDto {
DtoVal!(Undefined
On Tuesday, 19 July 2022 at 15:30:30 UTC, Bienlein wrote:
If the destination of a carrier was set to null, it implied
that the destination was currently undefined. Then the robot
brought the carrier to some rack where it was put aside for a
while till the planning system had created a new
why?
Because an empty string is, by default, represented by an empty
slice of the null pointer.
I don't program in D. I just read from time to time posts in the
D forum because of the good quality of what people write. So, I'm
not proficient in D, but in general internals should not boil
On Tuesday, 19 July 2022 at 10:29:40 UTC, Antonio wrote:
NULL is not the same that UNDEFINED
The distintion is really important: NULL is a valid value
(i.e.: The person phonenumber is NULL in database)... Of
course, you can represent this concept natively in you language
(Nullable, Optional
On Tuesday, 19 July 2022 at 08:10:25 UTC, Kagamin wrote:
On Monday, 18 July 2022 at 21:23:32 UTC, Antonio wrote:
I will study it in detail and report (if required). May be, I
will write the DTO problem with D article if I find time in
august.
In my experience null and empty in DTOs usually
On Monday, 18 July 2022 at 21:23:32 UTC, Antonio wrote:
I will study it in detail and report (if required). May be, I
will write the DTO problem with D article if I find time in
august.
In my experience null and empty in DTOs usually play the same
logical role. It's a very contrived
On Monday, 18 July 2022 at 17:20:04 UTC, Kagamin wrote:
... If you want such difference, use the Nullable wrapper or
Algebraic.
I do :-) In fact, I use algebraic types supporting Null and
Undefined for DTOs representation (and REST APIs). But I
discovered some "rare" si
On Monday, 18 July 2022 at 17:20:04 UTC, Kagamin wrote:
Difference between null and empty is useless.
Not really. `null` typically means that the value is missing,
irrelevant and not usable, which is quite different from having
"" as a usable value.
On Tuesday, 12 July 2022 at 20:36:03 UTC, Antonio wrote:
Honestly, it is difficult to understand for newcomers... there
is a reason, but there is a reason in javascript for `0 == ''`
too
People would have different preferences there. Difference between
null and empty is useless. D does
On Friday, 15 July 2022 at 11:12:07 UTC, Steven Schveighoffer
wrote:
Note that the term `null` and `[]` are special tokens that
morph type to whatever is most appropriate at the time. `null`
implicitly can be typed as any pointer type, or any array type.
`[]` can be typed as any array type
On Friday, 15 July 2022 at 06:38:58 UTC, Salih Dincer wrote:
Consider null type array which is a related topic but it cannot
get a null element! The first is ok, but the second is legal.
So no effect, is it normal?
```d
auto p = [ null, null ];//*
assert(
is(typeof(null
On Tuesday, 12 July 2022 at 22:58:32 UTC, Steven Schveighoffer
wrote:
```d
string a = "abcabc";
assert(a[0 .. 3] == a[3 .. $])
assert(a[0 .. 3] !is a[3 .. $])
```
The point is, `==` compares *value*, `is` always compares
*identity*.
Consider null type array which is a rel
Hi @Steven Schveighoffer,
Yes solution looking useful and sure it will work.
Thanks.
On 7/12/22 4:36 PM, Antonio wrote:
On Tuesday, 12 July 2022 at 18:56:43 UTC, Paul Backus wrote:
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
Because an empty string is, by default, represented by an empty slice
of the null pointer.
Do not rely on this, however; it's possible
On Tuesday, 12 July 2022 at 20:36:03 UTC, Antonio wrote:
Honestly, it is difficult to understand for newcomers... there
is a reason, but there is a reason in javascript for `0 == ''`
too
Correction
```d
string a = null;
assert(a is null);
assert(a == "");
string b = ""
On Tuesday, 12 July 2022 at 18:56:43 UTC, Paul Backus wrote:
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
Because an empty string is, by default, represented by an
empty slice of the null pointer.
Do not rely on this, however; it's possible sometimes to get
an empty string
an array. Never use null. use `[]` (empty array
literal).
Just to be clear: `[]` and `null` are the exact same thing
(null pointer, zero length). The reason to prefer `[]` over
`null` is purely for readability. The meaning is exactly the
same.
ah yes. The case I thought to was actually
```d
On 12.07.22 22:14, H. S. Teoh wrote:
Pedantically, no, they're not the same. You can assign null to a
pointer, but you can't assign [] to a pointer. `null` is a supertype of
`[]`.
But probably nobody actually cares about this distinction. :-D
If we're ignoring context, "null"
> Absolutely. I'd like to add: especially as default parameter value
> > that's an array. Never use null. use `[]` (empty array literal).
>
> Just to be clear: `[]` and `null` are the exact same thing (null
> pointer, zero length). The reason to prefer `[]` over `null` is purely
&g
On Tuesday, 12 July 2022 at 19:02:01 UTC, user1234 wrote:
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
[...]
Do not rely on this, however;
Absolutely. I'd like to add: especially as default parameter
value that's an array. Never use null. use `[]` (empty array
literal
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via
Digitalmars-d-learn wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
Because an empty string is, by default, represented by an empty
slice of the nu
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
Because an empty string is, by default, represented by an empty
slice of the null pointer.
Do not rely on this, however; it's possible sometimes to get an
empty string that isn't null, e.g., if you incrementally shrink
a slice over
On 7/12/22 10:11, Steven Schveighoffer wrote:
> The algorithm to compare *any* arrays is first verify the lengths are
> the same. Then for each element in the array, compare them. Since there
> are 0 elements in both the empty string and the null string, they are
> equal.
Che
On 7/12/22 12:40 PM, H. S. Teoh wrote:
Because an empty string is, by default, represented by an empty slice of
the null pointer.
No, it's not a null pointer. It's a pointer to a zero-character. But it
is indeed an empty slice.
-Steve
On 7/12/22 12:27 PM, Antonio wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
A string is not exactly a reference type. It's a length and a pointer.
This can be confusing to newcomers, especially ones that come from
languages that treat arrays and strings
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via
Digitalmars-d-learn wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
Because an empty string is, by default, represented by an empty
slice of the nu
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via Digitalmars-d-learn wrote:
> It works
>
> ```d
> void main()
> {
>assert(null=="");
> }
> ```
>
> why?
Because an empty string is, by default, represented by an empty slice of
the null poin
It works
```d
void main()
{
assert(null=="");
}
```
why?
On Thursday, 23 June 2022 at 16:16:26 UTC, vc wrote:
I've try this '\0'*10 and didn't work, i want the results be
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
```d
string nulls = '\0'.repeat(10).array;
```
— Bastiaan.
On Friday, 1 July 2022 at 15:35:00 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
I has been using this pattern each time something needs
special treatment when it can be null:
i'd prolly check `static if(is(typeof(null) : T))` which means
if the null literal
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
I has been using this pattern each time something needs special
treatment when it can be null:
i'd prolly check `static if(is(typeof(null) : T))` which means if
the null literal implicitly converts to type T.
there's also the bludgeon
On Friday, 1 July 2022 at 13:53:28 UTC, Antonio wrote:
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
-Why?
I realized Json is an struct (not an object)... and I supose,
it is managing null asignation manually (as a way to build
Json(null)).
-Whats the correct whay to test
On Friday, 1 July 2022 at 13:48:25 UTC, Antonio wrote:
-Why?
I realized Json is an struct (not an object)... and I supose, it
is managing null asignation manually (as a way to build
Json(null)).
-Whats the correct whay to test if something can be null?
That's my question :-p
I has been using this pattern each time something needs special
treatment when it can be null:
```d
void doSomething(T)(T v)
{
import std.traits: isAssignable;
static if( isAssignable!(T, typeof(null))) {
if(v is null)
writeln("This is null");
else
On Thursday, 23 June 2022 at 17:27:51 UTC, frame wrote:
On Thursday, 23 June 2022 at 16:16:26 UTC, vc wrote:
I've try this '\0'*10 and didn't work, i want the results be
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
One way:
```d
import std.range;
repeat("\0", 10).join("");
```
If you just
On Thursday, 23 June 2022 at 16:16:26 UTC, vc wrote:
I've try this '\0'*10 and didn't work, i want the results be
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
One way:
```d
import std.range;
repeat("\0", 10).join("");
```
I've try this '\0'*10 and didn't work, i want the results be
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
On Monday, 20 June 2022 at 19:08:32 UTC, max haughton wrote:
On Monday, 20 June 2022 at 17:48:48 UTC, Antonio wrote:
Is there any way to specify that a variable, member or
parameter can't be null?
You can use an invariant if it's a member of an aggregate but
be warned that these are only
On Monday, 20 June 2022 at 17:48:48 UTC, Antonio wrote:
Is there any way to specify that a variable, member or
parameter can't be null?
You can use an invariant if it's a member of an aggregate but be
warned that these are only checked at the boundaries of public
member functions.
On Monday, 20 June 2022 at 17:48:48 UTC, Antonio wrote:
Is there any way to specify that a variable, member or
parameter can't be null?
Depends on the type. Basic types can't be null. Pointers and
classes can always be `null`, though you could wrap them in a
custom library type that doesn't
Is there any way to specify that a variable, member or parameter
can't be null?
On Wednesday, 6 April 2022 at 08:55:43 UTC, BoQsc wrote:
I have a feeling that some parts of my code contains
unterminated strings and they do overflow into other string
[...]
If you suspect overflow, you can try string wrapping.
or not.
Please provide any relevant examples of how you do this.
In general, you shouldn't do that. In D, a `string`, `wstring`
and `dstring` are slices of corresponding character types, and
are *not* null-terminated (and in fact can contain 0 within their
representation). However, as Andrea
On Wednesday, 6 April 2022 at 08:55:43 UTC, BoQsc wrote:
I have a feeling that some parts of my code contains
unterminated strings and they do overflow into other string
that is to be combined. I'd like to take a look at strings,
analyse them manually and see if any of them end up terminated
I have a feeling that some parts of my code contains unterminated
strings and they do overflow into other string that is to be
combined. I'd like to take a look at strings, analyse them
manually and see if any of them end up terminated or not.
Please provide any relevant examples of how you
On Monday, 22 November 2021 at 13:21:22 UTC, bauss wrote:
Seems like it was only partially fixed then, specifically for
missing abstract methods, but not whether the signature was
correct or not.
Seems like a critical bug to me.
At least it's still present in dmd 2.098.
the null method
made its way to the binary.
You got it! It was an abstract class involved and the method
signature was just wrong, but no compile error. Thanks!
Seems like it was only partially fixed then, specifically for
missing abstract methods, but not whether the signature was
correct
On Sunday, 21 November 2021 at 02:43:12 UTC, Ali Çehreli wrote:
There are some offset arithmetic involved to get to the right
vtbl pointer but the pointer of an object cannot be stored
anywhere in the vtbl because there is just one vtbl but very
many objects.
Ok, so they mean by instance is
On 11/20/21 7:19 AM, frame wrote:
> I think this is true for an object instance. But from an interface
> instance, the object instance must be accessible somewhere?
Everything needed is available from the pointer to a class object (or
interface). There are some offset arithmetic involved to
On Friday, 19 November 2021 at 21:09:16 UTC, Ali Çehreli wrote:
I am not sure that's correct. The way I picture it, the code
reaches the __vptr by following a pointer; so it's already
known. Additionally, I am under the impression that there is
only one __vptr for a given type, which all
On 11/19/21 10:04 AM, frame wrote:
> On Friday, 19 November 2021 at 15:46:41 UTC, Adam D Ruppe wrote:
>
>> The `destroy` function (as well as other class destruction) will null
>> out the whole vtable to help make use-after-free an obvious error.
>> Possible that
On Friday, 19 November 2021 at 18:14:03 UTC, Adam D Ruppe wrote:
I've gotten that before as a result of a compiler bug... I had
an abstract method that wasn't implemented but the compile time
error got swallowed by a bug and thus the null method made its
way to the binary.
You got
and thus the null method made its
way to the binary.
I think that bug was fixed but still you might want to check
your code for the `abstract` keyword and ensure they are legit
implemented in your cases.
On Friday, 19 November 2021 at 15:46:41 UTC, Adam D Ruppe wrote:
The `destroy` function (as well as other class destruction)
will null out the whole vtable to help make use-after-free an
obvious error. Possible that happened to you.
So, a partial nulled table shouldn't exist, right? like
On Friday, 19 November 2021 at 15:37:59 UTC, frame wrote:
Is a null pointer entry in the __vptr[] valid or always a sign
for corruption/wrong cast somewhere? thx
The `destroy` function (as well as other class destruction) will
null out the whole vtable to help make use-after-free an obvious
Got a suspicious interface instance in the debugger and question
myself:
Is a null pointer entry in the __vptr[] valid or always a sign
for corruption/wrong cast somewhere? thx
On 10/15/21 6:39 AM, tastyminerals wrote:
On Thursday, 14 October 2021 at 12:43:36 UTC, jfondren wrote:
Do you have a complete example? Because this runs without error:
Steven Schveighoffer was correct, the error was caused by non explicit
`someVar;` which had to be changed to
)
writeln(a.get);
if (b.isNull)
writeln("b is null");
}
```
Steven Schveighoffer was correct, the error was caused by non
explicit `someVar;` which had to be changed to `someVar.get;`.
On 10/14/21 7:58 AM, tastyminerals wrote:
The new `DMD v2.097.2` deprecated implicit null conversions
`std.typecons.Nullable!double.Nullable.get_`.
The deprecation warning tell you to `Please use .get explicitly.`.
Here is an example code that doesn't work with the new compiler anymore
uot;b is null");
}
```
The new `DMD v2.097.2` deprecated implicit null conversions
`std.typecons.Nullable!double.Nullable.get_`.
The deprecation warning tell you to `Please use .get explicitly.`.
Here is an example code that doesn't work with the new compiler
anymore:
```
if (someValue.isNull)
```
Attempting
On Monday, 23 August 2021 at 13:00:36 UTC, DLearner wrote:
Hi
The code below compiles and runs producing 'Not null'.
```
void main()
{
import std.stdio;
int Var1;
int* ptrVar;
ptrVar =
if (ptrVar == null) {
writeln("Null");
} else {
writeln
Hi
The code below compiles and runs producing 'Not null'.
```
void main()
{
import std.stdio;
int Var1;
int* ptrVar;
ptrVar =
if (ptrVar == null) {
writeln("Null");
} else {
writeln("Not null");
}
}
```
However, should it
On Saturday, 24 July 2021 at 18:10:07 UTC, Alexey wrote:
The goal I with to achieve by this check - is to use template
and to assign value to variable basing on it's ability to
accept null as a value.
The most direct representation of that is __traits(compiles, (T
t) { t = null
On Saturday, 24 July 2021 at 20:10:37 UTC, JG wrote:
On Saturday, 24 July 2021 at 19:39:02 UTC, Alexey wrote:
[...]
There are probably better ways. However, this seems to work:
```d
import std;
enum canBeSetToNull(T) = __traits(compiles,(T.init is null));
interface I1
{
}
class C1 : I1
On Saturday, 24 July 2021 at 19:39:02 UTC, Alexey wrote:
On Saturday, 24 July 2021 at 18:10:07 UTC, Alexey wrote:
I've tried to use ```typeof(t) is cast(t)null```, but compiler
exits with error and so this can't be used for checking this
issue.
The goal I with to achieve by this check
On Saturday, 24 July 2021 at 18:10:07 UTC, Alexey wrote:
I've tried to use ```typeof(t) is cast(t)null```, but compiler
exits with error and so this can't be used for checking this
issue.
The goal I with to achieve by this check - is to use template
and to assign value to variable basing
I've tried to use ```typeof(t) is cast(t)null```, but compiler
exits with error and so this can't be used for checking this
issue.
The goal I with to achieve by this check - is to use template and
to assign value to variable basing on it's ability to accept null
as a value.
some testing
>
> > enum isAssignableNull(T) = is(T : Object) || isPointer(T);
> >
> > but how do I cover all cases?
>
> You can check if it's null with this `variable is null` and
> you can test it with assert as in `assert(variable is null);`
I mean a give type T n
l(T) = is(T : Object) || isPointer(T);
> > >
> > > but how do I cover all cases?
> >
> > You can check if it's null with this `variable is null` and you
> > can test it with assert as in `assert(variable is null);`
>
> I mean a give type T not variable
On Friday, 26 February 2021 at 23:37:18 UTC, Murilo wrote:
On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote:
I started with:
enum isAssignableNull(T) = is(T : Object) || isPointer(T);
but how do I cover all cases?
You can check if it's null with this `variable is null` and you
can
On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote:
I started with:
enum isAssignableNull(T) = is(T : Object) || isPointer(T);
but how do I cover all cases?
You can check if it's null with this `variable is null` and you
can test it with assert as in `assert(variable is null);`
?
Something like this should work:
enum isAssignableNull(T) = __traits(compiles, (T t) => t =
null);
`isAssignableNull!(immutable void*)` is true with his
definition but false with yours. Of course you are correct that
you cannot assign to an immutable pointer.
yep, it must be true for point
) = __traits(compiles, (T t) => t =
null);
`isAssignableNull!(immutable void*)` is true with his definition
but false with yours. Of course you are correct that you cannot
assign to an immutable pointer.
On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote:
I started with:
enum isAssignableNull(T) = is(T : Object) || isPointer(T);
but how do I cover all cases?
If I understand what you mean by "is assignable to null", this
should do it:
---
enum bool isAssignableNull(T) = is(t
On Friday, 26 February 2021 at 05:25:14 UTC, Jack wrote:
I started with:
enum isAssignableNull(T) = is(T : Object) || isPointer(T);
but how do I cover all cases?
Something like this should work:
enum isAssignableNull(T) = __traits(compiles, (T t) => t = null);
I started with:
enum isAssignableNull(T) = is(T : Object) || isPointer(T);
but how do I cover all cases?
On 2/17/21 4:16 PM, Adam D. Ruppe wrote:
On Wednesday, 17 February 2021 at 20:48:22 UTC, Martin wrote:
is this how it supposed to be? (https://run.dlang.io/is/7B4irm)
== compares contents. Both null and "" have empty contents and are
interchangable for operators that work o
On Wednesday, 17 February 2021 at 20:48:22 UTC, Martin wrote:
is this how it supposed to be? (https://run.dlang.io/is/7B4irm)
== compares contents. Both null and "" have empty contents and
are interchangable for operators that work on contents.
The assert just looks at t
Hi,
is this how it supposed to be? (https://run.dlang.io/is/7B4irm)
---
string a = null;
string t = "";
assert( ! a );
assert( t );
assert( t == a );
---
I have not expected assert(t == a) to be true - i would like to
know the argument for why this is correct when at the same ti
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
[...]
If it's not a bother, I'd like to know how you usually approach
it
[...]
Thanks!!!
I have a opDispatch sol
that *person*, or its *father* property can be null
Probably the incremental check solution. A helper function if I
find myself doing that more than two or three times.
On the other hand, I don't have to do this that often. I usually
design the functions to either except non-null values, or to
On Friday, 15 January 2021 at 14:25:09 UTC, Steven Schveighoffer
wrote:
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially
there's a default action for null for all
types/fields/methods, and everything else is passed through.
And now
)() if (__traits(hasMember, T,
mem)) {
alias Ret = typeof(() { return __traits(getMember,
*_val, mem); }());
if(_val is null) return NullCheck!(Ret)(null);
else return NullCheck!(Ret)(__trats(getMember, *_val,
mem));
}
bool opCast(V: bool)() { return _val !is null
On Friday, 15 January 2021 at 14:25:09 UTC, Steven Schveighoffer
wrote:
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially
there's a default action for null for all
types/fields/methods, and everything else is passed through.
And now
On 1/15/21 9:19 AM, Steven Schveighoffer wrote:
Something similar to BlackHole or WhiteHole. Essentially there's a
default action for null for all types/fields/methods, and everything
else is passed through.
And now reading the other thread about this above, it looks like this
type
__traits(getMember, *_val, mem);
}());
if(_val is null) return NullCheck!(Ret)(null);
else return NullCheck!(Ret)(__trats(getMember, *_val, mem));
}
bool opCast(V: bool)() { return _val !is null; }
}
auto nullCheck(T)(T *val) { return AutoNullCheck!T(val);}
// usage
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
This is only an open question to know what code patterns you
usually use to solve this situation in D
I
On Thursday, 14 January 2021 at 20:35:49 UTC, Dennis wrote:
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
If it's not a bother, I'd like to know how you usually
approach it
Usually I don't deal with null because my functions get
primitive types, slices, or structs. `ref
); }());
if(_val is null) return NullCheck!(Ret)(null);
else return NullCheck!(Ret)(__trats(getMember, *_val,
mem));
}
bool opCast(V: bool)() { return _val !is null; }
}
auto nullCheck(T)(T *val) { return AutoNullCheck!T(val);}
// usage
if(nullCheck(person).father.father
On Thursday, 14 January 2021 at 21:49:41 UTC, Christian Köstlin
wrote:
...
Did you have a look at https://code.dlang.org/packages/optional?
Especially
https://aliak00.github.io/optional/optional/oc/oc.html might go
in the right direction.
Kind regards,
Christian
Thats nice!!!
I was
like xml or json data that may be missing.
Yes, this is the usual situation (Personally, I use "DTO"
structured objects... that are serialized/unserialized to JSON)
So I just special cased those. My json lib doesn't return null
per se, it returns var(null) which is allowed to j
On 12.01.21 22:37, Jack wrote:
I was looking for a way to avoid null checks everywhere. I was checking
the Null object pattern, or use something like enforce pattern, or even
if I could make a new operator and implement something like C#'s .?
operator, that Java was going to have one
1 - 100 of 860 matches
Mail list logo
