After i'm sure, that this is a bug: Great work again.
If this bug will be fixed soon or someone can help me to find a
workaround, then NotNull would be exactly what I always wanted.
I made several tests with NotNull yesterday and actually they all
passed.
In special cases i didn't get a compiler error but then a runtime
error is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must
On 23.04.2012 12:06, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 09:14:12 +0200, Namespace rswhi...@googlemail.com
wrote:
I made several tests with NotNull yesterday and actually they all passed.
In special cases i didn't get a compiler error but then a runtime
error is better then nothing. :)
No. The whole point of NotNull is that it should enforce not
being null.
Allowing implicit casting from PossiblyNull to NotNull would
break this.
Then i'm further for a keyword that checks an object for not null.
Or you check at runtime to avoid null, e.g. with assert or
enforce.
On Monday, 23 April 2012 at 08:47:22 UTC, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 10:38:27 +0200, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 23.04.2012 12:06, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 09:14:12 +0200, Namespace
rswhi...@googlemail.com
wrote:
I made several tests
Am 23.04.2012 09:14, schrieb Namespace:
I made several tests with NotNull yesterday and actually they all passed.
In special cases i didn't get a compiler error but then a runtime error
is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void
On Sunday, 22 April 2012 at 16:59:05 UTC, Jesse Phillips wrote:
As such checkNotNull shoud be more than throwing an exception.
I have tried this, but it should get some constraints. Also
wouldn't the new lambda syntax look nice with null here: null
= unsafe(a)?
Yeah, I like this idea, though
On Sunday, 22 April 2012 at 10:58:10 UTC, Namespace wrote:
If i got you right on git, you wouldn't allow something like
this:
NotNull!(Foo) f = new Foo(); and instead you want that
everybody writes
NotNull!(Foo) f = assumeNotNull(new Foo);
Is that correct?
No, I think that's too annoying,
On Monday, 23 April 2012 at 11:04:24 UTC, Benjamin Thaut wrote:
Am 23.04.2012 09:14, schrieb Namespace:
I made several tests with NotNull yesterday and actually they
all passed.
In special cases i didn't get a compiler error but then a
runtime error
is better then nothing. :)
But there is
On Monday, 23 April 2012 at 14:31:05 UTC, Namespace wrote:
Yes, that's what i wrote a site before. Otherwise you couldn't
use it in other modules, that's right.
yeah i'll fix that next time i work on it.
I wouldn't write for all the objects which i would check
On Monday, 23 April 2012 at 14:50:14 UTC, Adam D. Ruppe wrote:
On Monday, 23 April 2012 at 14:31:05 UTC, Namespace wrote:
Yes, that's what i wrote a site before. Otherwise you couldn't
use it in other modules, that's right.
yeah i'll fix that next time i work on it.
I wouldn't write for all
I thought that something like this
// not_null_struct.d
NotNull!(T) assumeNotNull(T : Object)(T t) {
return NotNull!(T)(t);
}
@property
NotNull!(T) makeNotNull(T : Object)() {
T t = new T();
return assumeNotNull(t);
}
// not_null.d which import
On Monday, 23 April 2012 at 17:18:30 UTC, Namespace wrote:
I thought that something like this
// not_null_struct.d
NotNull!(T) assumeNotNull(T : Object)(T t) {
return NotNull!(T)(t);
}
@property
NotNull!(T) makeNotNull(T : Object)() {
T t = new T();
return
On Sunday, 22 April 2012 at 00:06:47 UTC, Adam D. Ruppe wrote:
I just pushed an update to git with
a few changes people have suggested.
I removed one of the old opAssigns
to keep a static type check.
Added assumeNotNull and checkNotNull
as entry points.
Made the data member private.
I think
On Sunday, 22 April 2012 at 00:06:47 UTC, Adam D. Ruppe wrote:
Made the data member private.
But if the struct is in a separate module you get an error.
So you must write
T get() {
return this._notNullData;
}
alias get this;
instead
alias _notNullData this; /// this is
On Sunday, 22 April 2012 at 00:06:47 UTC, Adam D. Ruppe wrote:
I just pushed an update to git with
a few changes people have suggested.
I removed one of the old opAssigns
to keep a static type check.
Added assumeNotNull and checkNotNull
as entry points.
I didn't recognized this part until
On Saturday, 21 April 2012 at 22:18:02 UTC, Adam D. Ruppe wrote:
We can do not null in the library reasonably
well. I have a basic one in github:
https://github.com/D-Programming-Language/phobos/pull/477
I'm thinking those interested in not null will want something
similar to the maybe type.
My question is, why D hasn't got an explicit Keyword to check at
compile time for non null references?
I understand that such check when they're implicit and refer to
all objects they slow down the programm, but why doesn't exist an
explicit keyword like @ref or a simple '@' before the Object
We can do not null in the library reasonably
well. I have a basic one in github:
https://github.com/D-Programming-Language/phobos/pull/477
On Saturday, 21 April 2012 at 22:18:02 UTC, Adam D. Ruppe wrote:
We can do not null in the library reasonably
well. I have a basic one in github:
https://github.com/D-Programming-Language/phobos/pull/477
So every time i want to avoid null references i have to write
NotNull!(Foo) f (or
On 04/21/2012 11:40 PM, Namespace wrote:
My question is, why D hasn't got an explicit Keyword to check at compile
time for non null references?
It shouldn't be a special keyword. If the compiler can do the necessary
analysis to actually enforce that the reference cannot hold a null
On 04/22/2012 12:48 AM, Namespace wrote:
On Saturday, 21 April 2012 at 22:18:02 UTC, Adam D. Ruppe wrote:
We can do not null in the library reasonably
well. I have a basic one in github:
https://github.com/D-Programming-Language/phobos/pull/477
So every time i want to avoid null references i
On Saturday, 21 April 2012 at 22:48:27 UTC, Namespace wrote:
So every time i want to avoid null references i have to write
NotNull!(Foo) f (or better, because it's a struct: ref
NotNull!(Foo) f)?
It is already a reference! Otherwise, it couldn't be null anyway.
But, yes, you'd write
I see you're right. Great! But it is only on git hub and not in
the standard typecons header in 2.059, right?
Adam D. Ruppe:
We can do not null in the library reasonably
well. I have a basic one in github:
https://github.com/D-Programming-Language/phobos/pull/477
It says:
I haven't actually used any NotNull in practice, but from the
attached tests, it looks like it will work well - hence, the
pull
On Saturday, 21 April 2012 at 23:18:40 UTC, Namespace wrote:
I see you're right. Great! But it is only on git hub and not in
the standard typecons header in 2.059, right?
But one thing: i missed there an invariant which check if t is
null.
If i write f.t = null; no error occured.
On Saturday, 21 April 2012 at 23:27:38 UTC, Namespace wrote:
But one thing: i missed there an invariant which check if t is
null.
If i write f.t = null; no error occured.
Don't do that!
Maybe I should make t private...
On Saturday, 21 April 2012 at 23:26:04 UTC, bearophile wrote:
I think before putting something in Phobos it's generally
better to have used it in Real Code for some time.
I agree, but this comes up a LOT on the newsgroup,
so I figure we need to get something up there to point
people to.
I am
I just pushed an update to git with
a few changes people have suggested.
I removed one of the old opAssigns
to keep a static type check.
Added assumeNotNull and checkNotNull
as entry points.
Made the data member private.
I think that's closer to what everyone
wants.
29 matches
Mail list logo
