View mode: basic / threaded / horizontal-split · Log in · Help
July 27, 2012
Re: A few questions
Short improvement: http://dpaste.dzfl.pl/f3263def
July 27, 2012
Re: A few questions
Simen Kjaeraas:

> I believe at least part of the explanation is that Walter wants 
> NotNull to
> implemented in a library. That's part of the reason for 
> introducing @disable this().

Yes, I remember part of the discussions. And I agree that 
generally it's better to put meta-features in a language that 
allow library code to implement the desired features.

That's why recently in the main D newsgroup I have said that 
built-in vector ops may be better replaced by library code 
(what's missing is some built-in trick to avoid the creation of 
intermediate arrays in complex expression).

But implementing good non-null types in library code is hard 
(rather harder than implementing vector ops in library code on 
library defined vectors). I think @disable isn't enough to cover 
what Spec# shows good non-null types are meant to be.

Bye,
bearophile
July 27, 2012
Re: A few questions
What's wrong with the solution that

void some_function(Foo? f) {

is converted to

void some_function(Foo f, string filename = __FILE__, uint line = 
__LINE__)  in {
    assert(f !is null, std.string.format("Null Object @ File %s 
on Line %d.", filename, line));
} body {

? It isn't a huge effort for the compiler, or?
July 27, 2012
Re: A few questions
On Fri, 27 Jul 2012 16:39:49 +0200, Namespace <rswhite4@googlemail.com>  
wrote:

> What's wrong with the solution that
>
> void some_function(Foo? f) {
>
> is converted to
>
> void some_function(Foo f, string filename = __FILE__, uint line =  
> __LINE__)  in {
>      assert(f !is null, std.string.format("Null Object @ File %s on Line  
> %d.", filename, line));
> } body {
>
> ? It isn't a huge effort for the compiler, or?

Nope.

But, that's just a simple assertion. If we'd had real non-nullable types,
we could remove the check completely, because you'd know it held a valid
object.

Now, a library solution has certain limitations a built-in solution would
not - for instance, new X would return non-nullable.

-- 
Simen
July 27, 2012
Re: A few questions
On Friday, July 27, 2012 12:29:13 Namespace wrote:
> 1.
> Why are these two method header identitcal?
> 
> const Foo some_function() {
> 
> and
> 
> Foo some_function() const {
> 
> ?

> const(Foo) but ref Foo. This is inconsistency, if you ask me.
> So why is between C++ and D such a huge difference?
> Why isn't it simply const Foo instead of const(Foo)?

Sadly, the reason is consistency. const is an attribute just like pure or 
nothrow, and you can do both

pure Foo func() {}

and

Foo func() pure {}

as well as

pure { Foo func() {} }

and

pure : Foo func() {}

If

const Foo func() {}

made Foo const rather than func, it would be inconsistent with the other 
attributes, and if const on func were only legal on the right (as in C++), 
then it would be inconsistent with the others. Many of us think that

const Foo func() {}

should just become illegal inconsistency or not because of all of this 
confusion, but Walter doesn't buy into that.

> 2.
> What's about a shorthand for debug assertions?
> E.g. to avoid not-null references (yes, if you're a windows user,
> you hate them):

Walter's stand on this is that the OS gives you null-dereferencing detection - 
i.e. segfaults and access violations. He's not going to add extra syntax for 
it.

- Jonathan M Davis
July 27, 2012
Re: A few questions
On Fri, 27 Jul 2012 17:35:19 +0200, Jonathan M Davis <jmdavisProg@gmx.com>  
wrote:

> Many of us think that
>
> const Foo func() {}
>
> should just become illegal inconsistency or not because of all of this
> confusion, but Walter doesn't buy into that.

Like monarch_dodra said, this is also a style favored by some:

@pure @property const
int foo() {
    //...
}

Having to write that

@pure @property
int foo() const {
    //...
}

at the very least feels weird.

int foo()
const @pure @property {
}

could work, I guess. But it feels backward.

-- 
Simen
July 27, 2012
Re: A few questions
On Friday, July 27, 2012 19:34:52 Simen Kjaeraas wrote:
> On Fri, 27 Jul 2012 17:35:19 +0200, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> > Many of us think that
> > 
> > const Foo func() {}
> > 
> > should just become illegal inconsistency or not because of all of this
> > confusion, but Walter doesn't buy into that.
> 
> Like monarch_dodra said, this is also a style favored by some:
> 
> @pure @property const
> int foo() {
>      //...
> }
> 
> Having to write that
> 
> @pure @property
> int foo() const {
>      //...
> }
> 
> at the very least feels weird.
> 
> int foo()
> const @pure @property {
> }
> 
> could work, I guess. But it feels backward.

Personally, I _always_ put the attributes on the right-hand side save for the 
ones which exist in C++ and Java (which is pretty much just the access 
specifiers, static, override, and final), and I think that it's ugly and 
confusing to have them on the left, but that's a matter of personal 
preference. const on the other hand constantly causes issues because - unlike 
the others - it can be applied to the return type as well. And the question 
comes up often enough that I think that it's a real problem and one that 
merits making putting it on the left illegal. At minimum, making it illegal on 
the left without other attributes between it and the return type should be 
illegal IMHO (though that could cause even more confusion depending on the 
error message, since then it might be confusing why you could put it on the 
left but only in some positions). That change isn't going to happen at this 
point, but I think that we'd be better off if it were.

- Jonathan M Davis
July 27, 2012
Re: A few questions
> Walter's stand on this is that the OS gives you 
> null-dereferencing detection -
> i.e. segfaults and access violations. He's not going to add 
> extra syntax for
> it.
>
> - Jonathan M Davis

That is a huge mistake. My OS prints me only a funny "Access 
violation". And so i can search for my little null reference by 
myself. I _must_ debug for a ridiculous null reference. That cost 
time. I have not even a filename or a line number. Only the 
message that something went wrong. And all other i have to find 
by myself. So much time for such little mistakes.

Why would Walter have a language which doesn't support good error 
handling?
D hasn't support for unused variables, unused imports and even 
not for null references. Why should everyone use D instead of any 
other language?
If i have a big project and i use many objects and one of them 
change to null, what now? Should the user really step through 
thousand lines of code because D prints only "Access Violation" 
without any further information? Or should i use the same 
principle as Java, and write every time again pre- and 
postconditions? I don't see any reasons why anybody should 
realize a big project with D and not with a other language, if 
the error handling and not null support remains as it is. Sorry.

To reject even a such handy shorthand is incomprehensible to me.
July 27, 2012
Re: A few questions
On Friday, July 27, 2012 20:07:56 Namespace wrote:
> > Walter's stand on this is that the OS gives you
> > null-dereferencing detection -
> > i.e. segfaults and access violations. He's not going to add
> > extra syntax for
> > it.
> > 
> > - Jonathan M Davis
> 
> That is a huge mistake. My OS prints me only a funny "Access
> violation". And so i can search for my little null reference by
> myself. I _must_ debug for a ridiculous null reference. That cost
> time. I have not even a filename or a line number. Only the
> message that something went wrong. And all other i have to find
> by myself. So much time for such little mistakes.
> 
> Why would Walter have a language which doesn't support good error
> handling?

Because a debugger will show you exactly where the problem is. So, why add 
checking that the OS already does for you? That's his logic. There are plenty 
of cases where that really isn't enough (e.g. you get a segfault on a server 
application without core dumps turned on when it's been running for 2 weeks), 
but it is for all the types of programs that Walter works on, so that's the 
way he thinks.

> D hasn't support for unused variables, unused imports and even
> not for null references. Why should everyone use D instead of any
> other language?
> If i have a big project and i use many objects and one of them
> change to null, what now? Should the user really step through
> thousand lines of code because D prints only "Access Violation"
> without any further information? Or should i use the same
> principle as Java, and write every time again pre- and
> postconditions? I don't see any reasons why anybody should
> realize a big project with D and not with a other language, if
> the error handling and not null support remains as it is. Sorry.
> 
> To reject even a such handy shorthand is incomprehensible to me.

Honestly, I think that you're blowing null pointer dereferences way out 
proportion. In my experience, they're rare, and I have to wonder what you're 
doing if you're seeing them all that often.

That being said, what I think we're likely to end up with is a signal handler 
in druntime which prints out a stacktrace when a segfault occurs (and does 
whatever the Windows equivalent would be on Windows). That way, you don't have 
to have null checks everywhere, but you still get the debug information that 
you need. But no one has done that yet.

- Jonathan M Davis
July 27, 2012
Re: A few questions
I also get null references (and every time i hate D a bit more), 
but mostly my classmates and other friends whom I've shown D. And 
most of them are already back to C++ or C#. And I can understand 
them.
If you want that D is sometimes taken seriously (and it reached 
only if you win more people for D), then perhaps you should do 
something for more usability.
Such small handy shorthands are easy to implement and even more 
understandable as a stacktrace.
1 2 3 4 5
Top | Discussion index | About this forum | D home