Index » Learn » A few questions (page 2)

July 27, 2012
Short improvement: http://dpaste.dzfl.pl/f3263def
July 27, 2012
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
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
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
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
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
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
> 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
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
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