Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529
On Wednesday, 28 February 2018 at 22:34:07 UTC, Dukc wrote: I don't think a just iterated array is automatically set to null, so taking it's pointer won't hit a memory-proteted area. So undeprectating arr.ptr in @safe would break @safety and be a step backward. If it cannot be proven safe by the compiler but is safe anyway it doesn't break @safe, it should just be @trusted. That's what @trusted is about, not about abusing functions to trick unsafe things into compiling @safe-ly. If this is an issue, one can define a @trusted function which takes a starting pointer from array and casts it to size_t before returning it so memory corruption cannot happen via it. On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote: Checking if an array is the slice of another. For that there is also std.array.overlap().
Re: Opt-in non-null class references?
On Wednesday, February 28, 2018 19:43:07 Kagamin via Digitalmars-d wrote: > On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M Davis > > wrote: > > Walter is almost always against features that require it, > > because it's so hard to get right > > Doesn't difficulty depend on what exactly to get right? It's not > a spherical problem in vacuum. Feel free to discuss any code-flow analysis issues with Walter, but he's consistently been against using it for much of anything whenever I've seen him discuss it. Not even stuff like VRP covers multiple lines of code, because doing so would require code-flow analysis. And he's specifically said that he's against using it for detecting when a null pointer is dereferenced. IIRC, he's stated that dmd's optimizer uses code-flow analysis for some stuff, but for anything that involves putting it in the frontend where the behavior would have to be encoded in the spec, he's been against it. - Jonathan M Davis
Re: C++ launched its community survey, too
On Wed, Feb 28, 2018 at 09:46:49PM +, TheFlyingFiddle via Digitalmars-d
wrote:
> On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
>
> Just to give some background. At work I spend most of my time
> maintaining legacy systems adding some small features or replacing
> subcomponents. So most of what I do is reading code and making some
> minor changes (unless it's buggy code then you get to rewrite :))
In spite of my job title being SW engineer, this actually almost exactly
describes what I do. :-D Well, OK, sometimes a larger feature is asked
for and I get to write fresh code, but 90% of my daily duties is reading
other people's code, fixing bugs, and making relatively minor changes.
[...]
> Perl is a maintenance nightmare. It just takes so much time to figure
> out what the code actually does. Particularity if it has been changed
> by multiple people over the years.
That applies to almost any code changed by a large number of people over
the years. :-D Especially when it's code written in a commercial
environment where there's a high turnover and people are forced to
implement last-minute hacks due to customer demands and impractically
tight deadlines. Over time, the hacks accumulate on top of each other
into a brittle tower of cards that pretty much is guaranteed to break at
the slightest change, mostly in apparently unrelated places where you
won't notice until something blows up later.
Sometimes I just have to shake my head and walk away, and admit defeat
that I *don't* understand what the code does, and neither do I want to,
because I might need therapy afterwards. :-D
> That's the main reason Perl is at the top of my most disliked
> languages.
In my case, that also applies to badly-maintained C/C++ code!
[...]
> > And the whole thing about == vs === is just one huge WAT. It "makes
> > sense" if you understand why it's necessary, but it just begs the
> > question, why, oh why, wasn't the language designed properly in the
> > first place so that such monstrosities aren't necessary?!
>
> Another personal favorite.
> function foo($myArray) {
>return $myArray['test'];
> }
>
> $myString = "hello, world";
> $test = foo($myString);
>
> echo $test; // $test = 'h'; Because you know 'test' auto converts to 0.
Hahaha... yeah. This is one of the things that make me hate dynamically
typed languages so much. Your types can change from under you at any
time without any warning, usually with disastrous consequences, but
should you be so unlucky as to have said consequences masked by more
"convenient" auto type conversions, you quickly find yourself wishing
for a real type system. Like when you mistype the name of an optional
field in a data structure, and the receiving code simply ignores the
mistyped field. No warnings or indications whatsoever of what went
wrong.
[...]
> > > Compared to them, programming in C++ or Java for that matter is
> > > like a dream.
> >
> > C++ is hardly any better, actually:
> >
> > https://bartoszmilewski.com/2013/09/19/edward-chands/
>
> Yeah... C++ is interesting in that way. Mostly what I have seen is
> that for any given project they have a strict policy of how to do
> memory management and error handling.
Yes, essentially the only way to work with C++ in a sane way is to
restrict yourself, either by convention or by policy, to a strict subset
of C++. Google, for example, places heavy restrictions on what parts of
C++ are allowed in their codebase. Full C++ contains just too many
pathological things that code that's actually free-for-all in that way
quickly becomes completely unmaintainable.
Reminds me of a C++ project I had to work with once, where useful work
was done in dtors via side-effects. Good luck figuring out what the
code does from glancing at it! (It begins with a mystified "why does
this function only contain some variable declarations and nothing
else?", and goes downhill from there.)
> Also it's not really a pleasure reading C++ templates :D.
C++ template syntax makes me cringe every time I see it. Reminds me of
all those battle scars I accumulated in the 2 decades or so I was
actively using C++.
[...]
> The awful and nice part of Java is that since your forced to do things
> a certain way then things will actually be done in that way. In this
> case OOP and all of that. It's nice when you read the code, awful when
> you actually have to code in it.
I dunno, I've seen Java code written in a way that's anything but OO,
with 10-page long functions that contain essentially the entire program,
and other clear symptoms of spaghetti code and general cloudiness in the
author's mind. All "nicely" wrapped up, of course, in a class, complete
with a bow-tie, in lip service to OO.
As somebody once said, A true programmer can write assembly code in any
language. :-D
> > > Only thing missing is the ability to do arbitrary system calls
> > > during compilation :D
> >
> > AKA
> > compile-my-source-code-and-get-a-t
Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529
I don't think a just iterated array is automatically set to null, so taking it's pointer won't hit a memory-proteted area. So undeprectating arr.ptr in @safe would break @safety and be a step backward. If this is an issue, one can define a @trusted function which takes a starting pointer from array and casts it to size_t before returning it so memory corruption cannot happen via it. On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote: Checking if an array is the slice of another. For that there is also std.array.overlap().
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 20:01:34 UTC, H. S. Teoh wrote:
Just to give some background. At work I spend most of my time
maintaining legacy systems adding some small features or
replacing subcomponents. So most of what I do is reading code and
making some minor changes (unless it's buggy code then you get to
rewrite :))
The idea of sigils is actually not a bad one. It does, after
all, have basis in natural languages. But the way it was
implemented in Perl is, shall we say, rather quirky, leading to
all sorts of unexpected interactions with other things and
generally become a cognitive burden in large projects, where a
disproportionate amount of time is spent fighting with syntax
rather than getting things done. (E.g., is it @$x[$y] or $x->y
or ${x}{y} or ${x->$y}[$z] or something else?)
Perl is a maintenance nightmare. It just takes so much time to
figure out what the code actually does. Particularity if it has
been changed by multiple people over the years.
That's the main reason Perl is at the top of my most disliked
languages.
Yeah, that's 10 trains worth of WATs right there. :-D
And the whole thing about == vs === is just one huge WAT. It
"makes sense" if you understand why it's necessary, but it just
begs the question, why, oh why, wasn't the language designed
properly in the first place so that such monstrosities aren't
necessary?!
Another personal favorite.
function foo($myArray) {
return $myArray['test'];
}
$myString = "hello, world";
$test = foo($myString);
echo $test; // $test = 'h'; Because you know 'test' auto converts
to 0.
Now PHP does have many WATs but it's still simpler to read than
Perl so it has an edge over Perl for me atleast.
Compared to them, programming in C++ or Java for that matter
is like a dream.
C++ is hardly any better, actually:
https://bartoszmilewski.com/2013/09/19/edward-chands/
Yeah... C++ is interesting in that way. Mostly what I have seen
is that for any given project they have a strict policy of how to
do memory management and error handling. Also it's not really a
pleasure reading C++ templates :D.
Java... well, Java is a walled garden, a somewhat nice (if
verbose) one that's somewhat detached from reality, but
forcefully anchored to it by big commercial interests. As a
language it's not too bad; the core language is pretty nicely
designed -- in an idealistic, ivory tower sort of sense.
But in practice, it's more of a Write Once, Debug Everywhere
deal. The verbosity and IDE dependence sucks. The OO
fanaticism also sucks (singleton classes IMO is a big code
smell, esp. when it's really just syntactic lip service to the
OO religion for what's essentially global functions). The lack
of real generics is total suck, and a showstopper for me. Even
the half-hearted attempt at generics that they shoehorned into
it later doesn't fully save it from being sucky. The only
saving grace of Java is the extensive library support -- you
can find just about anything you might imagine as a library,
which saves you from dealing with the suckier parts of the
language. Most of the time.
The awful and nice part of Java is that since your forced to do
things a certain way then things will actually be done in that
way. In this case OOP and all of that. It's nice when you read
the code, awful when you actually have to code in it.
Only thing missing is the ability to do arbitrary system calls
during compilation :D
AKA
compile-my-source-code-and-get-a-trojan-installed-on-your-system. :-D If this ?
(mis)feature ever gets merged into DMD, give me a call right
away -- I have a lot of source code to sell you. For free. :-D
Why must you ruin my perfect plan of getting a free botnet! :D
Re: C++ launched its community survey, too
On Wed, Feb 28, 2018 at 06:45:29PM +, TheFlyingFiddle via Digitalmars-d
wrote:
[...]
> My least preferredlanguage of all times would be Perl. With (PHP 5.3)
> coming in at a close second :)
>
> Perl is just... I get it, you can write somewhat nicer bash scripts in
> the language.
I was actually a Perl (5) fan for many years, before finding D. As you
said, it's very nice for replacing brittle (and ugly!) shell scripts,
not to mention with superior performance instead of spawning a
subprocess (somtimes multiple) for basically every command, even
fundamental things like evaluating an expression. (Though bash may have
built-in some of it... but still.)
PHP is just... well, OK, one has to admit that the idea of embedding
code in HTML and vice versa in a smooth syntax that you can easily
transition into and out of, was an extremely clever one. It removed the
burden of constant escaping (aka the leaning toothpick syndrome) that
was prevalent in such kind of code back in the day. But other than
that.. PHP has some pretty serious fundamental design flaws that became
calcified as features because just about everything depended on it, and
after a while, it was just a monster of a language, most eloquently
described as:
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
> But people... they just go with it and build these huge crazy systems
> that somehow 10+ years later become my problem.
Yeah... Perl is great for one-off scripts and clever hacks. But the way
it's designed also makes it not very scalable. Once you get past a
certain size, the quirky syntax and general looseness (in typing,
semantics, data structures, etc.) just start becoming more and more of a
maintenance burden.
At least, that was the case for Perl 5, which was around the time I
found D and left Perl behind. Can't speak for Perl 6 or later.
> The designer of Perl was clearly insane. Let's store everything in fun
> global "invisible" variables, functions don't specify arguments... And
> lets have the first letter of the variable define how/what $, @, %,
> with fun auto conversions everywhere :D.
The idea of sigils is actually not a bad one. It does, after all, have
basis in natural languages. But the way it was implemented in Perl is,
shall we say, rather quirky, leading to all sorts of unexpected
interactions with other things and generally become a cognitive burden
in large projects, where a disproportionate amount of time is spent
fighting with syntax rather than getting things done. (E.g., is it
@$x[$y] or $x->y or ${x}{y} or ${x->$y}[$z] or something else?)
D's dot syntax, by comparison, is worlds better. One dot to rule 'em
all. Symmetry is powerful. ;-)
> PHP is better but there is some really weird stuff in it.
Actually, IMO, PHP is far worse than Perl. Perl is pretty crazy, yeah,
but it does have a certain kind of logic behind it (albeit a twisted
one, just like its creator :-P), a kind of consistency that makes you go
"yeah, in retrospect it *does* make sense, even though it's still really
weird". PHP, OTOH, is full of exceptions and corner cases *without* any
underlying consistency. There is no pattern to it, not even a twisted
one, it's just a bunch of arbitrary exceptions and special cases that
you basically have to memorize. And random things just Don't Work(tm),
just because they don't, for no discernible reasons whatsoever. Like
the inability to overload class constructors, even though polymorphism
is supported, a very strange combo. And the word "overload" is used in
a strange, different sense, just to confuse you.
> Of the top of my head is the auto type conversion system. This works,
> by design...
>
> //PHP
> $a = 5;
> $b = $a * "10 trains";
> echo $b; //$b is now 50... Fun and interesting stuff right there
Yeah, that's 10 trains worth of WATs right there. :-D
And the whole thing about == vs === is just one huge WAT. It "makes
sense" if you understand why it's necessary, but it just begs the
question, why, oh why, wasn't the language designed properly in the
first place so that such monstrosities aren't necessary?!
> Compared to them, programming in C++ or Java for that matter is like a
> dream.
C++ is hardly any better, actually:
https://bartoszmilewski.com/2013/09/19/edward-chands/
Java... well, Java is a walled garden, a somewhat nice (if verbose) one
that's somewhat detached from reality, but forcefully anchored to it by
big commercial interests. As a language it's not too bad; the core
language is pretty nicely designed -- in an idealistic, ivory tower sort
of sense.
But in practice, it's more of a Write Once, Debug Everywhere deal. The
verbosity and IDE dependence sucks. The OO fanaticism also sucks
(singleton classes IMO is a big code smell, esp. when it's really just
syntactic lip service to the OO religion for what's essentially global
functions). The lack of real generics is total suck, and a showstopper
for me. Even the half-hearted attempt at
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M Davis wrote: Walter is almost always against features that require it, because it's so hard to get right Doesn't difficulty depend on what exactly to get right? It's not a spherical problem in vacuum.
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 13:43:37 UTC, SimonN wrote: Hi, Andrei said in 2014 that not-null-references should be the priority of 2014's language design, with consideration to make not-null the default. In case the code breakage is too high, this can be an opt-in compiler flag. [...] I've slowly come around to supporting this idea. I'd rather avoid segfaults in the first place and avoid extra effort checking for null if possible. It also sets clearer expectations for a user. For example, D now: Class func(T param); // user always needs to worry about if the return value is null or not, there may be that edge case where it is null D with non-nullable references: Class func(T param); // user knows that the return value will not be null, no need to check Nullable!Class func(T param); // user knows they need to check for null and handle it. That's my two cents anyways
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 10:15:13 UTC, Zoadian wrote: On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit wrote: It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! yes c++ is not the greatest language (thats why i use D). but java is the worst language i've ever used. My least preferredlanguage of all times would be Perl. With (PHP 5.3) coming in at a close second :) Perl is just... I get it, you can write somewhat nicer bash scripts in the language. But people... they just go with it and build these huge crazy systems that somehow 10+ years later become my problem. The designer of Perl was clearly insane. Let's store everything in fun global "invisible" variables, functions don't specify arguments... And lets have the first letter of the variable define how/what $, @, %, with fun auto conversions everywhere :D. PHP is better but there is some really weird stuff in it. Of the top of my head is the auto type conversion system. This works, by design... //PHP $a = 5; $b = $a * "10 trains"; echo $b; //$b is now 50... Fun and interesting stuff right there Compared to them, programming in C++ or Java for that matter is like a dream. But when I can, I always use D. Mainly because unlike every other language, it has static introspection, ctfe and mixins. A whole new world of expressive power is gained by this. Only thing missing is the ability to do arbitrary system calls during compilation :D
Re: How do you get comfortable with Dlang.org's Forum?
H. S. Teoh wrote: On Fri, Feb 23, 2018 at 10:01:44PM +, bachmeier via Digitalmars-d wrote: On Friday, 23 February 2018 at 17:56:29 UTC, Biocyberman wrote: Speaking on behalf of myself, after additional inputs from many excellent and respectful users in this 'forum'. I can say that, on the scale of 1 (least geeky) to 10 (most geeky), I would put forum.dlang.org to the level 8 of geekiness required to use the forum. It may be natural for long-time users, but for newcomers, it is very challenging. Hold it right there. You're saying that it's a bad thing for a *programming language* forum to have a high geekiness rating? Implying that *programmers* (y'know, ostensibly the target audience of said forum) are not geeky enough to know how to operate a geeky forum? Whoa. I think I need to sit down. I don't mean to go into the good vs bad direction. What I was saying is that it is hard to get comfortable and use the forum the most effective/convenient ways. The forum should not be a technical barrier for members to communicate conveniently. With that said, I am glad that I put up the questions and got a bunch of useful tips to use the forums. FYI, the most useful one is to install a NNTP client and use the 'forum' the way it is, a NNTP server with a web interface. I have to admit that I don't understand this. I don't think it would be possible for it to be simpler to use this forum. No registration needed, plain text messages, just click "Reply" and type in your message. Additional features would make it more complicated. Well, obviously non-programmers (or should I say, "non-geeky programmers", whatever that might mean) have every right to be able to operate a forum dedicated for a programming language without any undue handicaps, so we have to make concessions on the level of "geekiness" required to participate in the programming language discussions that take place here, such that said discussions would be more accessible to said non-programmers (or "non-geeky" programmers, whoever they may be). P.S. I think my geekiness-11 brain just blew several fuses and 2 transistors. Please excuse me while I take a break to go off to the brain shop to replace them. Maybe I'll pick up an oxymoron compensation diode on the way as well. We need to take a break sometimes, too much geekiness everywhere slows us down. At least that my experience. > T
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 19:03:54 UTC, Mark wrote: On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote: On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei I have submitted, already. My major complaints boils down to the fact that they refuse to deprecated features due to religious like devotions to backwards compatibility support. You're not the only one who thinks so - https://www.youtube.com/watch?v=ND-TuW0KIgg ;) Modules couldn't make it but we have a new syntactic sugar for SFINAE. [someone should make for Dlang too]
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 12:06:38 UTC, Stefan Koch wrote: On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves wrote: On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila You do ? Please link me to your progress if you can. I had an earlier version with could successfully #include nanomsg, then I ran into problems doing the same thing with curl, and restarted from scratch. My DConf talk submission is on this. Atila
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M Davis wrote: On Wednesday, February 28, 2018 13:43:37 SimonN via Digitalmars-d wrote: [...] I expect that pretty much anything you propose that requires code flow analysis is DOA. Walter is almost always against features that require it, because it's so hard to get right, and the places that D does use it tend to have problems (e.g. it's actually quite trivial to use a const or immutable member variable before it's initialized). In fact, IIRC, in the most recent discussion on having the compiler give an error when it can detect that a null pointer or reference is being dereferenced, Walter was arguing against precisely because code-flow analysis is so hard to get right, and encoding it in the spec is particularly bad (which would be required for anything involving errors). If non-nullable references were added to D, I expect that they would have to be like structs marked with [...] I don't understand the problems with null either - my program segfaults, I look at the core dump and initialise whatever it is that was T.init. And this in the rare case I actually use a pointer or a class instance to begin with. I also declare nearly every variable with `const var = ;`, so I guess that makes it even more unlikely for me. Atila
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 15:29:17 UTC, Mike Franklin wrote: You might be interested in this little experiment: https://github.com/dlang/dmd/pull/7375 Indeed, this looks extremely useful, at the very least in a linter. I probably rely on ints getting initialized to 0 throughout the program, and only rarely make that explicit. With null references, the problem is not forgetting the initialization; it's expressing the intent of the variable. Usually, I want the non-null, but sometimes, I want a nullable reference and would like to require the using code to test the reference for null. Merely verifying for initialization doesn't help here; it may well be intended that null will be assigned later to the reference. -- Simon
Re: How to stringify a template instantiation expression?
On Wednesday, 28 February 2018 at 15:09:56 UTC, Yuxuan Shui wrote: For a template instantiation expression like A!(B, C!(D, E)), I want to get a string "A!(B, C!(D, E))", better if A, B, C, D, E is replaced by fully qualified name. Is this possible? A!(B, C!(D, E)).stringof I guess. Will print the former. There's a Learn forum as well btw :) Cheers
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 13:43:37 UTC, SimonN wrote: Hi, Andrei said in 2014 that not-null-references should be the priority of 2014's language design, with consideration to make not-null the default. In case the code breakage is too high, this can be an opt-in compiler flag. You might be interested in this little experiment: https://github.com/dlang/dmd/pull/7375 Mike
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 14:05:19 UTC, Jonathan M Davis wrote: I expect that pretty much anything you propose that requires code flow analysis is DOA. Walter was arguing against precisely because code-flow analysis is so hard to get right, Thanks, that's an important judgement. I've read the 3 threads that I found around this issue, but didn't notice this sentiment before that code-flow analysis is so problematic. Yeah, non-null class fields hinge on code-flow analysis. And I'll accept that pushing non-null refs won't lead to anything if the necessary code-flow analysis is too tricky for the benefit. I've never understood why some folks have so many problems with null pointers. My gripe is that the necessarily-nullable class reference doesn't express the intent. Either a codebase must rely on silent conventions or every function with asserts. and that blows up quite quickly such that it's fixed quite quickly. Yeah, I admit that most null crashes surface adequately quickly even when you have to run the program first. It's merely sad to see D, with all its powerful static inspection, rely on runtime tests for nulls while other languages (Kotlin, Zig, and 2017 C#) rule null out at compile-time, as if it's the most natural thing in the world. -- Simon
How to stringify a template instantiation expression?
For a template instantiation expression like A!(B, C!(D, E)), I want to get a string "A!(B, C!(D, E))", better if A, B, C, D, E is replaced by fully qualified name. Is this possible?
Re: Opt-in non-null class references?
On Wednesday, February 28, 2018 13:43:37 SimonN via Digitalmars-d wrote: > Answer: Both A?.init and A.init shall be null, then use code-flow > analysis. I expect that pretty much anything you propose that requires code flow analysis is DOA. Walter is almost always against features that require it, because it's so hard to get right, and the places that D does use it tend to have problems (e.g. it's actually quite trivial to use a const or immutable member variable before it's initialized). In fact, IIRC, in the most recent discussion on having the compiler give an error when it can detect that a null pointer or reference is being dereferenced, Walter was arguing against precisely because code-flow analysis is so hard to get right, and encoding it in the spec is particularly bad (which would be required for anything involving errors). If non-nullable references were added to D, I expect that they would have to be like structs marked with @disable this(); with all of the cons that go with that. > Argument: It's not worth it. I'm very much in that camp. I've never understood why some folks have so many problems with null pointers. Personally, about the worst that I normally have to deal with is forgetting to initialize class reference or pointer, and that blows up quite quickly such that it's fixed quite quickly. And that's in C++, D, Java, or any other language that I've used. Null pointers/references are simply not something that I've ever seen much of a problem with even when I use pointers heavily. And as idiomatic D code tends to use classes rarely, it's that much less useful for D than it would be for many other languages. I know that some folks think that null is a huge problem, and some folks use classes or pointers much more than idiomatic D typically does, but I definitely don't think that adding a new type of pointer or reference to the language to try to deal with null pointers/references is worth the extra complication. It's a huge complication for what I personally believe is a small problem, though obviously, not everyone agrees on that point. I have no idea what Walter and Andrei's current stances on such an idea are other than the fact that Walter is very much against using code-flow analysis for something like verifying that a pointer or reference has been initialized before it's dereferenced. - Jonathan M Davis
Opt-in non-null class references?
Hi,
Andrei said in 2014 that not-null-references should be the
priority of 2014's language design, with consideration to make
not-null the default. In case the code breakage is too high, this
can be an opt-in compiler flag.
Discussion here:
https://forum.dlang.org/post/lcq2il$2emp$1...@digitalmars.com
Everybody in the 2014 thread was hyped, but has anything ever
happened in the language? In November 2017, the D forum discussed
C#'s non-null warnings. Has anybody thought about this again
since?
In D, to prevent immense breakage, non-nullable class references
need to be opt-in. I would love to see them and don't mind
adapting my 25,000-line D-using project during a weekend.
Are there any counter-arguments to why non-nullable
references/pointers haven't made it into D yet? Feel free to
attack my answers below.
* * *
Argument: If A denotes non-null reference to class A, it can't
have an init value.
Answer: Both A?.init and A.init shall be null, then use code-flow
analysis.
This would match D's immutable: In a class constructor, you may
assign the value 5 to a field of type immutable(int) that has
init value 0. The compiler is happy as long as it can prove that
we never write a second time during this constructor, and that we
never read before the first assignment.
Likewise, it should be legal to assign from A to another A
expression such as new A(), and the compiler is happy as long as
the reference is assigned eventually, and if the reference is
never read before assignment. (I haven't contributed to the
compiler, I can't testify it's that easy.)
To allow hacks, it should remain legal to cast A? (nullable
reference) to A (non-nullable). This should pass compilation
(because casting takes all responsibility from the compiler) and
then segfault at runtime, like any null dereference today.
* * *
Argument: I shall express non-null with contracts.
Answer: That's indeed the best solution without any language
change. But it's bloaty and doesn't check anything at
compile-time.
class A { }
void f1(A a) in { assert(a); } do { f2(a); }
void f2(A a) in { assert(a); } do { f3(a); }
void f3(A a) in { assert(a); } do { ...; }
void g(A a) { if (a) ...; else ...; }
Sturdy D code must look like this today. Some functions handle
the nulls, others request non-null refs from their callers. The
function signature should express this, and a contract is part of
the signature.
But several maintenance problems arise from non-null via contract.
First issue: We now rely on unit-testing to ensure our types are
correct. You would do that in dynamic languages where the type
system can't give you meaningful diagonstic errors otherwise. I'd
rather not fall back to this in D. It's easy to forget such
tests, coverage analysis doesn't help here.
Second issue: Introducing new fields requires updating all
methods that uses the fields. This isn't necessarily only the
methods in the class. If you have this code:
class B {
A a1;
void f1() in { assert(a1); } do { ... }
void f2() in { assert(a1); } do { ... }
}
When you introduce more fields, you must update every method.
This is bug-prone; we have final-switch (a full-blown language
feature) just to solve similar issues:
class B {
A a1;
A a2;
void f1() in { assert(a1); assert(a2); } do { ... }
void f2() in { assert(a1); /+ forgot +/ } do { ... }
}
Third issue: Most references in a program aren't null. Especially
class references that are fields of another class are often
initialized in the constructor once, and never re-set. This is
the predominant use of references. In D, the default, implicit
case should do the Right Thing; it's fine when nonstandard
features (allowing null) are explicit.
Assuming that A means non-null A, I would love this instead:
class A { }
void f1(A a) { f2(a); }
void f2(A a) { f3(a); }
void f3(A a) { ...; }
void g(A? a) { if (a) ...; else ...; }
Or:
void g(A @nullable a) { if (a) ...; else ...; }
Code-flow analysis can already statically check that we
initialize immutable values only once. Likewise, it should check
that we only pass A? to f1 after we have tested it for non-null,
and that we only call methods on A? after checking for its
non-null-ness (and the type of `a' inside the `if' block should
probably still be A?, not A.)
* * *
Argument: null refs aren't a problem, they're memory-safe.
Answer: Memory-safety is not the concern here. Readability of
code is, and preventing at compiletime what safely explodes at
runtime.
* * *
Argument: Roll your own non-null type as a wrapper around D's
nullable class reference.
Answer: That will look ugly, is an abstraction inversion, and
checks at runtime only.
class A { }
struct NotNull(T)
if (is(T == class))
{
T payload;
@disable this();
this(T t) {
assert(t !is null);
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 11:32:32 UTC, Atila Neves wrote: On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila You do ? Please link me to your progress if you can.
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. I think you can have C plus another language just fine. In C++ you use extern "C" as a wrapper, you could easily run a completely different parser within an extern "C" block and build a different type of AST for it. This was probably out of reach in the 80s and early 90s when compiler resources was an issue, but with LLVM and gigabytes of RAM I think it would be quite reasonable to do something like that. People don't do it because the basic counter argument always is "but we already support C through linkage", but that doesn't mean that there would be no real productivity advantage to building C into the language. Not that I would do it if I designed a system level language, mostly because I think it would be better to build tools for transpiling code from C to the new language. C is a dead end now, I think. Ola
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 20:46:20 UTC, bachmeier wrote: On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis wrote: The other problem is that many of C++'s problems come from being a superset of C, which is also a huge strength, and it would be a pretty huge blow to C++ if it couldn't just #include C code and use it as if it were C++. To truly fix C++ while retaining many of its strengths would require fixing C as well, and that's not happening. That's why it would be a big deal to be able to directly include C header files in D projects (as was discussed around here not that long ago). I'm working on this. Atila
Re: implicit construction operator
On Monday, 26 February 2018 at 21:36:49 UTC, ketmar wrote: aliak wrote: It makes libraries *much* more intuitive and expressive (C++ just got it wrong by choosing the wrong default). If you allow library authors to opt in instead of opt out then it becomes a conscious decision for one. library authors can create overloads for various argument types. with `foo(T...) (T args)` it is possible to generate conversions with CTFE. so we *already* have such feature. No, we do not. Presumably you're not suggesting every function ever written has to be a template, and has to manually support every custom type ever written's chosen implicit conversions?
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote: On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] [...] Not strictly true. My old C++98 project no longer compiled with the latest g++, because it contained things allowed in C++98 that are no longer allowed in C++17. Some things were relatively simple to fix, but others were quite painful to fix, so I ended up using --std=c++11 as a workaround instead. In the frustrating process of trying to fix things C++17 complains about, I threw in the towel and decided to rewrite it in D instead. [...] The fun with C++ the same expression means completely different things in C++98 and C++11 fon< fun< 1 >>::three >::two >::one and there's no context change, it's parsing rules that changed. https://gustedt.wordpress.com/2013/12/18/right-angle-brackets-shifting-semantics
Re: C++ launched its community survey, too
On Wednesday, 28 February 2018 at 00:53:16 UTC, psychoticRabbit wrote: It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! yes c++ is not the greatest language (thats why i use D). but java is the worst language i've ever used.
Re: Can this be done? Defining type as in this Scala sample code
On Monday, 26 February 2018 at 19:36:33 UTC, Simen Kjærås wrote:
On Monday, 26 February 2018 at 15:43:54 UTC, Bienlein wrote:
object Scratch extends App {
// compiles:
val list = List(1, 2.4, 5)
val sum = list.sum
println(sum)
// does not compile:
val list2 = List(1, 2.4, 5, "123")
val sum2 = list2.sum
println(sum2)
}
There's nothing in the language or standard library that
supports this. However, it's perfectly possible to make
something with those semantics:
import std.variant;
import std.stdio;
struct List(T) {
T[] values;
alias values this;
}
auto list(T...)(T args)
{
import std.traits : CommonType;
static if (is(CommonType!T == void))
List!Variant result;
else
List!(CommonType!T) result;
result.length = T.length;
foreach (i, e; args) {
result[i] = e;
}
return result;
}
auto sum(T)(List!T lst)
if (is(typeof(lst[0] + lst[0])) && !is(T == Variant))
{
T result = 0;
foreach (e; lst) {
result += e;
}
return result;
}
unittest {
auto list1 = list(1, 2.4, 5);
auto sum1 = list1.sum;
writeln(sum1);
auto list2 = list(1, 2.4, 5, "123");
auto sum2 = list2.sum;
writeln(sum2);
}
Since std.variant.Variant does operator overloads, we have to
explicitly check if T == Variant in the sum function. For
Variant, that's probably the correct choice. We could use
Algebraic instead, but it also does operator overloads, even
when no type in its arguments support them. Again, we could
create our own - Algebraic and Variant are library types, after
all.
--
Simen
Didn't have time so far to look into this. But thanks anyway.
Re: Can this be done? Defining type as in this Scala sample code
On Monday, 26 February 2018 at 16:53:39 UTC, drug wrote:
you can do something like this (https://run.dlang.io/is/RYR5Dm):
```
import std.algorithm : sum;
import std.range : only;
import std.stdio : writeln;
import std.typecons : tuple;
void main()
{
{
auto list = tuple(1, 2.4, 5);
auto sum = list.expand.only.sum;
writeln(sum);
}
{
// do not compile
/*
auto list = tuple(1, 2.4, 5, "123");
auto sum = list.expand.only.sum;
writeln(sum);
*/
}
}
```
This looks good. It's not completely transparent, because of this
"expand.only" thing. But I guess it can be done to hide it.
Thanks for this one.
