When I was first playing with D, I managed to create a segfault
by doing `SomeClass c;` and then trying do something with the
object I thought I had default-created, by analogy with C++
syntax. Seasoned D programmers will recognise that I did nothing
of the sort and instead created c is null an
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so I
just don't see it as a big deal. You lose a matter of seconds,
realize the mistake, and fix it.
What is your
On 11/19/18 4:23 PM, Jordi Gutiérrez Hermoso wrote:
When I was first playing with D, I managed to create a segfault by doing
`SomeClass c;` and then trying do something with the object I thought I
had default-created, by analogy with C++ syntax. Seasoned D programmers
will recognise that I did
On Mon, 19 Nov 2018 21:23:31 +, Jordi Gutiérrez Hermoso wrote:
> When I was first playing with D, I managed to create a segfault by doing
> `SomeClass c;` and then trying do something with the object I thought I
> had default-created, by analogy with C++ syntax. Seasoned D programmers
> will re
On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer
wrote:
A null pointer dereference is an immediate error, and it's also
a safe error. It does not cause corruption, and it is free (the
MMU is doing it for you).
Is this always true for all arches that D can compile to? I
reme
On 11/19/18 7:21 PM, Jordi Gutiérrez Hermoso wrote:
On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote:
A null pointer dereference is an immediate error, and it's also a safe
error. It does not cause corruption, and it is free (the MMU is doing
it for you).
Is this alway
On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote:
Programmers coming from nearly any language other than C++
would find it expected and intuitive that declaring a class
instance variable leaves it null.
What do you think about making the syntax slightly more explicit
and war
On Tuesday, 20 November 2018 at 00:30:44 UTC, Jordi Gutiérrez
Hermoso wrote:
Yeah, maybe this bit of C++ syntax isn't the best idea. What
about other alternatives?
You could try testing for null before dereferencing ;-)
If the following code in D, did what you'd reasonably expect it
to do,
On Tue, 20 Nov 2018 00:30:44 +, Jordi Gutiérrez Hermoso wrote:
> On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh wrote:
>
>> Programmers coming from nearly any language other than C++ would find
>> it expected and intuitive that declaring a class instance variable
>> leaves it null
On Monday, November 19, 2018 5:30:00 PM MST Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 11/19/18 7:21 PM, Jordi Gutiérrez Hermoso wrote:
> > On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote:
> >> A null pointer dereference is an immediate error, and it's also a
On Tuesday, 20 November 2018 at 00:30:44 UTC, Jordi Gutiérrez
Hermoso wrote:
On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh
wrote:
[...]
What do you think about making the syntax slightly more
explicit and warn or possibly error out if you don't do it that
way? Either
Some
On Tuesday, 20 November 2018 at 03:24:56 UTC, Neia Neutuladh
wrote:
On Tue, 20 Nov 2018 00:30:44 +, Jordi Gutiérrez Hermoso
wrote:
On Monday, 19 November 2018 at 21:57:11 UTC, Neia Neutuladh
wrote:
Programmers coming from nearly any language other than C++
would find it expected and intui
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a m
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a m
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
Why does nobody seem to think that `null` is a serious problem
in D?
Because the more you learn about D the less you want to use
classes. I view class as compatibility feature when you want to
port Java code to D
On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
This only applies to little scripts and unittests maybe.
Not when you're writing any kind of relatively larger
application that involves being run for longer or if there's
more possible permutations of your state variables.
Umm... if
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
by doing `SomeClass c;` and then trying do something with the
object I thought I had default-created, by analogy with C++
syntax.
D is more similar to Ja
On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
Does D have a linter which warns about certain style of coding
like this?
dscanner might check it. I don't know though.
On Tuesday, 20 November 2018 at 09:27:03 UTC, aberba wrote:
Does D have a linter which warns about certain style of coding
like this?
AFAIK, dscanner does some linting.
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initialize it. You're supposed to
initialize *everything* anyway.
On Tue, 20 Nov 2018 15:29:50 +, Kagamin wrote:
> On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
>> This only applies to little scripts and unittests maybe.
>>
>> Not when you're writing any kind of relatively larger application that
>> involves being run for longer or if there's mor
On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis
wrote:
For @safe to function properly, dereferencing null _must_ be
guaranteed to be memory safe, and for dmd it is, since it will
always segfault. Unfortunately, as understand it, it is
currently possible with ldc's optimizer to
On 11/20/18 1:04 PM, Johan Engelen wrote:
On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis wrote:
For @safe to function properly, dereferencing null _must_ be
guaranteed to be memory safe, and for dmd it is, since it will always
segfault. Unfortunately, as understand it, it is c
On Tuesday, 20 November 2018 at 15:29:50 UTC, Kagamin wrote:
On Tuesday, 20 November 2018 at 11:11:43 UTC, aliak wrote:
This only applies to little scripts and unittests maybe.
Not when you're writing any kind of relatively larger
application that involves being run for longer or if there's
m
Try to learn D.
Put writeln in deconstructor to prove it works as expected
Make random changes, program never runs again.
Takes 30+ minutes to realize that writeln("my string") is fine,
but writeln("my string " ~ value) is an allocation / garbage
collection which crashes the program without a st
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class objects explicit, which
makes it harder to see where the dereference is happening.
Again, the terms are confusing. You just said the dere
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
But really, it's the act of using a pointer to read/write the
data it points at which causes the segfault. And in D, we
assume that this action is @safe because of the MMU protecting
the first page.
This is like me
On Tue, 20 Nov 2018 23:14:27 +, Johan Engelen wrote:
> When you don't call `a.foo()` a dereference, you basically say that
> `this` is allowed to be `null` inside a class member function. (and then
> it'd have to be normal to do `if (this) ...` inside class member
> functions...)
That's what w
On Tuesday, November 20, 2018 8:38:40 AM MST Kagamin via Digitalmars-d-learn
wrote:
> On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
>
> Hermoso wrote:
> > When I was first playing with D, I managed to create a segfault
> > by doing `SomeClass c;` and then trying do something with th
On Tuesday, November 20, 2018 11:04:08 AM MST Johan Engelen via Digitalmars-
d-learn wrote:
> On Tuesday, 20 November 2018 at 03:38:14 UTC, Jonathan M Davis
>
> wrote:
> > For @safe to function properly, dereferencing null _must_ be
> > guaranteed to be memory safe, and for dmd it is, since it will
On Tuesday, 20 November 2018 at 15:46:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initialize it. You're supposed to
initialize *everything* anyway.
a fan
On Tuesday, 20 November 2018 at 23:14:27 UTC, Johan Engelen wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class objects explicit,
which makes it harder to see where the dereference is
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a m
On Wednesday, 21 November 2018 at 10:47:35 UTC, NoMoreBugs wrote:
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe
wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you r
On Wednesday, 21 November 2018 at 11:53:14 UTC, Alex wrote:
Am I misled, or isn't this impossible by design?
´´´
import std.stdio;
import std.random;
class C
{
size_t dummy;
final void baz()
{
if(this is null)
{
wri
On Wednesday, 21 November 2018 at 14:21:44 UTC, Kagamin wrote:
A value passed to ref parameter is assumed to be initialized.
C# would reject to call function foo.
This was not my point. I wonder, whether the case, where the
compiler can't figure out the initialization state of an object
is
On Wed, 21 Nov 2018 17:00:29 +, Alex wrote:
> C# wouldn't reject the case above, would it?
C# *would* reject that (you can't call any methods on a null object), but
in D, it compiles and runs and doesn't segfault.
On Wednesday, 21 November 2018 at 10:47:35 UTC, NoMoreBugs wrote:
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe
wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you r
On Wednesday, 21 November 2018 at 17:09:54 UTC, Neia Neutuladh
wrote:
On Wed, 21 Nov 2018 17:00:29 +, Alex wrote:
C# wouldn't reject the case above, would it?
C# *would* reject that (you can't call any methods on a null
object), but in D, it compiles and runs and doesn't segfault.
No, i
On Wednesday, 21 November 2018 at 09:20:01 UTC, NoMoreBugs wrote:
On Tuesday, 20 November 2018 at 15:46:35 UTC, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initiali
On Wednesday, 21 November 2018 at 17:46:29 UTC, Alex wrote:
compiled against 4.6.1 Framework.
However, of course, there is a NullReferenceException, if c
happens to be null, when calling baz.
So the difference is not the compiler behavior, but just the
runtime behavior...
How could the com
On Wed, 21 Nov 2018 20:15:42 +, welkam wrote:
> In D classes are reference type and unless you mark them as final they
> will have vtable.
Even if you mark your class as final, it has a vtable because it inherits
from Object, which has virtual functions. The ProtoObject proposal is for a
bas
On Wednesday, 21 November 2018 at 09:31:41 UTC, Patrick Schluter
wrote:
On Tuesday, 20 November 2018 at 23:14:27 UTC, Johan Engelen
wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class
On Wednesday, 21 November 2018 at 07:47:14 UTC, Jonathan M Davis
wrote:
IMHO, requiring something in the spec like "it must segfault
when dereferencing null" as has been suggested before is
probably not a good idea is really getting too specific
(especially considering that some folks have ar
On Wednesday, 21 November 2018 at 03:05:07 UTC, Neia Neutuladh
wrote:
Virtual function calls have to do a dereference to figure out
which potentially overrided function to call.
"have to do a dereference" in terms of "dereference" as language
semantic: yes.
"have to do a dereference" in term
On Wednesday, 21 November 2018 at 21:05:37 UTC, aliak wrote:
On Wednesday, 21 November 2018 at 17:46:29 UTC, Alex wrote:
compiled against 4.6.1 Framework.
However, of course, there is a NullReferenceException, if c
happens to be null, when calling baz.
So the difference is not the compiler b
On Wednesday, 21 November 2018 at 17:11:23 UTC, Stefan Koch wrote:
For _TRIVIAL_cases this is not hard.
But we cannot only worry about trivial cases;
We have to consider _all_ cases.
Therefore we better not emit an error in a trivial case.
Which could lead users to assume that we are detecting
On Wednesday, 21 November 2018 at 17:00:29 UTC, Alex wrote:
This was not my point. I wonder, whether the case, where the
compiler can't figure out the initialization state of an object
is so hard to construct.
´´´
import std.experimental.all;
class C
{
size_t dummy;
final void
On Wednesday, 21 November 2018 at 22:24:06 UTC, Johan Engelen
wrote:
The issue is not specific to LDC at all. DMD also does
optimizations that assume that dereferencing [*] null is UB.
Do you have an example? I think it treats null dereference as
implementation defined but otherwise safe.
On Wednesday, 21 November 2018 at 23:27:25 UTC, Alex wrote:
Nice! Didn't know that... But the language is a foreign one for
me.
Nevertheless, from what I saw:
Shouldn't it be
var x: C?
as an optional kind, because otherwise, I can't assign a nil to
the instance, which I can do to a class insta
On 11/20/18 6:14 PM, Johan Engelen wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class objects explicit, which makes
it harder to see where the dereference is happening.
Again, the
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
by doing `SomeClass c;` and then trying do something with the
object I thought I had default-created, by analogy with C++
syntax. Seasoned D programmers wi
On Thursday, 22 November 2018 at 15:38:18 UTC, Per Nordlöw wrote:
The natural way forward for D is to add static analysis in the
compiler that tracks use of possibly uninitialized classes (and
perhaps also pointers). This has been discussed many times on
the forums. The important thing with su
On Thu, 22 Nov 2018 15:50:01 +, Stefan Koch wrote:
> I'd say the problem here is not just false positives, but false
> negatives!
False negatives are a small problem. The compiler fails to catch some
errors some of the time, and that's not surprising. False positives are
highly vexing becaus
On Wednesday, November 21, 2018 3:24:06 PM MST Johan Engelen via
Digitalmars-d-learn wrote:
> On Wednesday, 21 November 2018 at 07:47:14 UTC, Jonathan M Davis
>
> wrote:
> > IMHO, requiring something in the spec like "it must segfault
> > when dereferencing null" as has been suggested before is
>
On Thursday, 22 November 2018 at 15:50:01 UTC, Stefan Koch wrote:
I'd say the problem here is not just false positives, but false
negatives!
With emphasis on _incremental_ additions to the compiler for
covering more and more positives without introducing any _false_
negatives whatsoever. With
On Thursday, 22 November 2018 at 23:10:06 UTC, Per Nordlöw wrote:
With emphasis on _incremental_ additions to the compiler for
covering more and more positives without introducing any
_false_ negatives whatsoever. Without loosing compilation
performance.
BTW, should such a compiler checking i
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
What's the reasoning for allowing this?
100 % agree that there should be non-nullable class references,
they're my main missing feature in D. Likewise,
On Monday, 19 November 2018 at 21:23:31
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
I'm not the only one who has done this. I can't find it right
now, but I've seen at least one person open a bug report
because they misunderstood this as a bug in dmd.
I have
On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
What's the reasoning for allowing this?
100 % agree that there should be non-nullable clas
On Friday, 30 November 2018 at 06:15:29 UTC, O-N-S (ozan) wrote:
On Monday, 19 November 2018 at 21:23:31
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
I'm not the only one who has done this. I can't find it right
now, but I've seen at least one person open a bug
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote:
On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a
segfault
What's the reasoning for al
On Friday, 30 November 2018 at 15:32:55 UTC, 12345swordy wrote:
On Friday, 30 November 2018 at 12:00:46 UTC, Atila Neves wrote:
On Thursday, 29 November 2018 at 18:31:41 UTC, SimonN wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
[...]
[...]
100 % agree
isocpp.org just had a link to a blog post where someone makes a
case for uninitialized variables in C++ being an advantage in
that you can potentially get a warning regarding use of an
uninitialized variable that points out an error in your code.
https://akrzemi1.wordpress.com/2018/11/22/treat
On Saturday, 1 December 2018 at 00:32:35 UTC, Tony wrote:
isocpp.org just had a link to a blog post where someone makes a
case for uninitialized variables in C++ being an advantage in
that you can potentially get a warning regarding use of an
uninitialized variable that points out an error in y
On Friday, 30 November 2018 at 15:32:55 UTC, 12345swordy wrote:
NotNullable!MyClassImpl = (MyClassImpvar != Null) ?
MyClassImpvar : new MyClassImpvar();
AFAIK it's something like
NotNullable!MyClassImp m = MyClassImpvar.orElse(new MyClassImp());
On Saturday, 1 December 2018 at 11:16:49 UTC, Dukc wrote:
This is great when it works, but the problem is that it would
be gargantuan effort -and compile time sink- to make it work
perfectly. When it's just about if-else if chains, switches or
boolean logic as in the example, the analysis won't
On Sat, Dec 01, 2018 at 06:30:05PM +, Tony via Digitalmars-d-learn wrote:
> On Saturday, 1 December 2018 at 11:16:49 UTC, Dukc wrote:
> > This is great when it works, but the problem is that it would be
> > gargantuan effort -and compile time sink- to make it work perfectly.
> > When it's just
On Saturday, 1 December 2018 at 19:02:54 UTC, H. S. Teoh wrote:
But that's precisely the problem. It's not always possible to
tell whether a variable has been initialized. E.g.:
int func(int x) {
int *p;
if (solveRiemannHypothesis()) {
On Saturday, 1 December 2018 at 20:41:53 UTC, Sebastiaan Koppe
wrote:
Since the compiler can prove which branch is taken, the analyse
has to assume both are.
*can't*
On Saturday, 1 December 2018 at 19:02:54 UTC, H. S. Teoh wrote:
In the above contrived example, Artin's conjecture is implied
by the Riemann hypothesis, so the second if statement would
only run if p is initialized. But there is no way the compiler
is going to be able to deduce this, especial
On Saturday, 1 December 2018 at 19:02:54 UTC, H. S. Teoh wrote:
But that's precisely the problem. It's not always possible to
tell whether a variable has been initialized. E.g.:
To me, the possibility of a "false positive" doesn't preclude the
use of a warning unless that possibility is lar
On 22.11.18 16:19, Steven Schveighoffer wrote:
In terms of language semantics, I don't know what the right answer is.
If we want to say that if an optimizer changes program behavior, the
code must be UB, then this would have to be UB.
But I would prefer saying something like -- if a segfault
Nulls/Nones are always a big gap in a language's type system. A
common alternative is to have some Option/Maybe type like Rust
or Haskell or D's Variant. How about making that required to
plug the null gap?
There are others too who feel like that too:
https://news.ycombinator.com/item?id=1858
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
When I was first playing with D, I managed to create a segfault
by doing `SomeClass c;` and then trying do something with the
object I thought I had default-created, by analogy with C++
syntax. Seasoned D programmers wi
75 matches
Mail list logo
