Article: Why Const Sucks
Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis My biggest issues with const are, as you wrote, ranges and postBlit. I still use `const` everywhere unless I can't. I used to use `immutable`, but gradually came around to only using it if I have to send data to another thread, otherwise it's too much of a hassle. Atila
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Brilliant article, Johathan! I feel the same...
Re: LDC 1.8.0
On Monday, 5 March 2018 at 07:45:04 UTC, Johannes Loher wrote: Will there also be a armhf Release? Yep; it'll most likely be up this evening (CET).
Re: Article: Why Const Sucks
Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement. Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words.
Re: Article: Why Const Sucks
On Monday, March 05, 2018 11:38:05 Atila Neves via Digitalmars-d-announce wrote: > I used to use `immutable`, but gradually came around to only > using it if I have to send data to another thread, otherwise it's > too much of a hassle. Aside from the whole std.concurrency situation, I generally use immutable in the places where the semantics are the same as const, so it doesn't generally cause a problem for me. I just prefer immutable in the cases where it and const are the same, because immutable clearly indicates that the value never changes, so immutable more closely fits the idea even if const happens to mean that in that particular case. I agree that using immutable where you have to do stuff like design objects in a particular way in order to make immutable work is generally too much of a pain to be worth it, but at least in those cases, the data can then be shared across threads, and it's data that doesn't need mutable backdoors, because it only makes sense to use immutable in that fashion when the object is really designed to never change state. I think that the only time that I've programmed heavily in a way that involves immutability everywhere is when I programmed in Haskell, and that combined with the fact that Haskell is lazy and completely functional such that you can't use imperative idioms anywhere made it so that each line of Haskell code took me more time to write than is the case with any other language I've used (except maybe batch, because of how insanely error-prone it is). I think that I'm a better programmer for it, but I'd hate to program that way normally, and using immutable all over the place would head too heavily in that direction - though at least D, unlike Haskell, is a multi-paradigm language and allows you to choose to use a particular idiom when you think it makes the most sense instead of forcing it everywhere. - Jonathan M Davis
Re: Article: Why Const Sucks
On Monday, March 05, 2018 13:48:23 Adam D. Ruppe via Digitalmars-d-announce wrote: > Just a semantic note, it is "straitjacket". "straight" is like a > non-wiggly line. "strait" means narrow or constricted. Thus, the > straitjacket is a jacket that constricts your movement. > > Of course, using "straight" is such a common mistake it has > become generally accepted... but still, I like being precise with > my words. Thanks for the correction. I probably knew at some point, but it's not a word that I use often, and I didn't even think about looking it up. Now, I'm more likely to remember in the future. - Jonathan M Davis
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: Excellent read! I enjoyed the history of proposed solutions. I've run into the trouble with annotated opEquals in classes several times. I believe an empty/nonexistant Object class is the correct solution, together with templates. If it breaks tricky opEquals-overriding usercode, then so be it. The const trouble is merely a symptom here, the real problem is Object. In structs, all const members feel alien, they preventing all copying. This seems far harder to solve. -- Simon
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: So as to the main thrust, I generally agree. In fact, I think const is almost useless even if you want to use it fully: you said immutable is better in many places, and yes, but in addition to that, inout is better than const in most the remaining cases. Constructing a const variable? Almost completely useless - immutable is better in almost all (if not actually all) cases. Referencing function parameters? inout is better in all cases except just plain input. If there's any part of it being returned - as is the case on most member methods to me at least - inout is flat-out better. And then, of course, like you said "don't use it" is the solution to most of the const system's flaws anyway which seems to be the case with a lot of D's add-on qualifiers.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Great read for a Monday.
Re: Article: Why Const Sucks
On Monday, March 05, 2018 13:53:21 SimonN via Digitalmars-d-announce wrote: > On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: > > Here's something I wrote up on const: > Excellent read! I enjoyed the history of proposed solutions. > > I've run into the trouble with annotated opEquals in classes > several times. I believe an empty/nonexistant Object class is the > correct solution, together with templates. If it breaks tricky > opEquals-overriding usercode, then so be it. The const trouble is > merely a symptom here, the real problem is Object. Yes, the fact that those functions are on Object is a serious problem that affects more than const, but part of the reason for explaining that particular issue was to show how the use of const - or the lack thereof - on a member function can have serious consequences for a class hierarchy. It's by far the worst in the case of Object, because it affects _all_ classes in D, but any time that someone designs a class in D that is intendend to then have other classes derived from it, the same choices pop up; the consequences are just then on a smaller scale. > In structs, all const members feel alien, they preventing all > copying. This seems far harder to solve. Yeah. I don't know what we do about that. In general, I think that it makes by far the most sense for value types to not be inherently const (even in part), so I'm not all that worried about the problems that stem from making a particular member variable const. But the fact that you then can't use a postblit constructor with a const object - even if nothing in the object is const unless the entire object is const - is definitely a problem. IIRC, Walter's take on it was that it was bad design for objects to deep-copy like that and that it was just better to use stuff like COW, in which case, postblit constructors aren't generally needed. And as such, he's a lot less worried about the problem than otherwise might be the case. I agree that it's frequently problematic for copying to be expensive in that manner, but it's also sometimes very useful. I expect that a good, solid DIP on the subject would be accepted in spite of the fact that Walter isn't big on postblit constructors, but first, someone has to come up with such a DIP, and that's not even vaguely easy - especially if the answer doesn't involve adding a copy constructor to the language (which I would guess would be rejected due the extra complexity that it would add to the language, but I don't know). Either way, right now, it's just one more thing on the list of things that makes it difficult enough to use const in D that many of us use it fairly minimally. - Jonathan M Davis
Re: mysql-native v2.2.0: Maintenance Release (and news)
On 3/4/18 12:17 AM, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == Tagged 'v2.2.0'. Full changelog: https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md Thanks, Nick for all your work on this! -Steve
Re: mysql-native v2.1.0
On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == [...] Is unix socket connection supported? I'm not seeing any information about it in the docs.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 13:49:43 UTC, Jonathan M Davis wrote:
On Monday, March 05, 2018 11:38:05 Atila Neves via
Digitalmars-d-announce wrote:
I used to use `immutable`, but gradually came around to only
using it if I have to send data to another thread, otherwise
it's too much of a hassle.
Aside from the whole std.concurrency situation, I generally use
immutable in the places where the semantics are the same as
const, so it doesn't generally cause a problem for me. I just
prefer immutable in the cases where it and const are the same,
because immutable clearly indicates that the value never
changes, so immutable more closely fits the idea even if const
happens to mean that in that particular case. I agree that
using immutable where you have to do stuff like design objects
in a particular way in order to make immutable work is
generally too much of a pain to be worth it, but at least in
those cases, the data can then be shared across threads, and
it's data that doesn't need mutable backdoors, because it only
makes sense to use immutable in that fashion when the object is
really designed to never change state.
I think that the only time that I've programmed heavily in a
way that involves immutability everywhere is when I programmed
in Haskell, and that combined with the fact that Haskell is
lazy and completely functional such that you can't use
imperative idioms anywhere made it so that each line of Haskell
code took me more time to write than is the case with any other
language I've used (except maybe batch, because of how insanely
error-prone it is). I think that I'm a better programmer for
it, but I'd hate to program that way normally, and using
immutable all over the place would head too heavily in that
direction - though at least D, unlike Haskell, is a
multi-paradigm language and allows you to choose to use a
particular idiom when you think it makes the most sense instead
of forcing it everywhere.
- Jonathan M Davis
I prefer const over immutable because this compiles:
string[] arr;
const _ = arr;
While this does not:
string[] arr;
immutable _ = arr;
Basically, const just works and immutable is a hassle unless
threads are involved. There are other situations where immutable
is needed / should be preferred as well, notably:
struct Foo {
const(ubyte)[] bytes;
}
Construct Foo from a mutable buffer that you're reusing to get
network traffic and you're going to have a bad time.
Atila
Re: Release D 2.079.0
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Interesting read and it explains some of the incomprehensible error messages. Basically you're saying we've got a strong const in D but essentially the situation is much like in Java because the general approach is don't use it ? Kind of ironic. I made a Logger module a couple years back and I used const very generously. Then came the moment where the LogWriters actually had to do the writing. One would assume that a function called 'stdio.write' mutates some state, but it sure as hell doesn't affect the state of my logger. DMD said: So swy! writeln not const-y, no can do, swy! So I remove const. One function at a time and end up with a module where basically no const remains. But it doesn't stop there. Since logger isn't const anymore, it now can't be used in any const functions. So more de-const-ification happened... Also, it's frustrating to have to get rid of const because Object.toString uses some Outputwriter thing which is not const and therefore transitively you can't have const anywhere else. Kind of a disappointing experience. As far as I'm concerned, it's not so much "don't use const; or, it's not worth it" but more like "I would if I could but I can't so I shan't". I bother with const as much as possible but it's incredible frustrating and I would argue the time lost to de-const-ify APIs is easily equivalent to a code breaking change that would make const more applicable. Something possimpible. Like a compiler that doesn't purely make decisions upon a const keyword, but one that can understand that interacting with some random function with only "in" parameters or objects, which aren't even interacting with,or are part of, the object's internal state and are just passed through, can't violate the const-ness of the object. But there's likely much more to consider than that and I couldn't ever dream of implementing such a thing..unfortunately
Re: Release D 2.079.0
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Good stuff. Still bothers me that we had to special case "throw new Exception();" in order to make it nogc. I can't think of any better ways right now, but I wish it was more explicit.
Re: Article: Why Const Sucks
On Mon, Mar 05, 2018 at 03:57:35AM -0700, Jonathan M Davis via
Digitalmars-d-announce wrote:
> Here's something I wrote up on const:
>
> http://jmdavisprog.com/articles/why-const-sucks.html
>
> I suppose that it's not exactly the most positive article, but I feel
> that it's accurate.
[...]
Yeah, I found myself in the same boat recently. As you often say, const
and ranges simply don't mix. And modern idiomatic D is 90% about
ranges, so that alone instantly reduces the scope of const's usefulness
by a lot.
A case in point: I was implementing a container recently, and wrote an
opSlice() method to return a range over its elements. My initial thought
was that it could be made const, since the range wouldn't mutate the
underlying elements, but only represent a mutable slice over a const
container, i.e., the slice can mutate, but the elements cannot, just
like iterating over string (== immutable(char)[]). Should be easy,
right?
struct Container {
auto opSlice() const {
static struct Result {
private Container impl;
private int n; // internal mutable state
@property bool empty() { ... }
... // rest of range API
}
return Result(this);
}
}
Well, that didn't work, because in opSlice, `this` is const, and I can't
initialize Result.impl which is a mutable Container. Well, no biggie,
just make it const:
struct Container {
auto opSlice() const {
static struct Result {
private const(Container) impl;
private int n; // internal mutable state
@property bool empty() { ... }
... // rest of range API
}
return Result(this);
}
}
At first, this worked, and it seems that I could have my const cake and
eat it too. Until I decided at some point that I needed to make it a
forward range, which requires a .save method. So I tried:
...
static struct Result {
private const(Container) impl;
...
@property Result save() {
Result copy = this;
return this;
}
}
That seemed to do the trick, everything compiles and works. But I soon
ran into an unfixable problem: the resulting range, while it works in
the simplest cases, started causing mysterious compile errors when I
tried to use it with Phobos range algorithms. Eventually, I discovered
that the underlying problem was that Result, as defined above, was a
struct with a const member, and therefore it was illegal to assign it to
a variable of the same type outside of initialization (since doing do
meant you were overwriting a const field with something else, which
violates the constness of the field). This broke the by-value
assumption inherent in much of Phobos code, so the resulting range ended
being unusable with most Phobos algorithms. Which defeated the whole
purpose in the first place.
While I'm sure with enough time and patience Phobos could be fixed to
support this kind of range, the decision I was faced with was: should I
(1) persist in using const, and thereby stall my project while I work on
huge chunks of Phobos range algorithms to make them usable with ranges
that have const members (not to mention spending how much time waiting
in the Phobos PR queue and potentially getting things rejected because
it might cause breakage of unknown amounts of existing code), or (2)
just remove `const` from my code, and be able to continue with my
project *right now*? The choice was a no-brainer, sad to say.
So yeah, while D's const provides actual guarantees unlike C++'s
laughable const-by-documentation, that also limits its scope so much
that in practice, it's rarely ever used outside of built-in types like
string. Which also limits the usefulness of its guarantees so much that
it's questionable whether it's actually worth the effort.
T
--
It won't be covered in the book. The source code has to be useful for
something, after all. -- Larry Wall
Re: Article: Why Const Sucks
Very interesting and well written! Jonathan, your experiences
with const in C++/Java just about matches my experiences with it.
I also feel that the situation in D is less than ideal in this
regard.
First, a small (for sure copy-pasta) typo in your article:
const(int[]) arr1 = getArray();
const(int)[] arr2 = p1; //Sure you meant arr2 = arr1;
Regarding the proposed solution to the issues with Object namely
"the solution to this problem which was agreed to a few years ago
was to remove opEquals, opCmp, toHash, and toString from Object
so that derived classes can define them with whatever attributes
are desired" which, you say, will never happen because of too
much code breakage...
What about the following? Currently the compiler is smart enough,
so you can define class Foo and explicitly inherit from Object if
you prefer:
class Foo : Object {..} //OK, no recursive Object inherits Object
ad-infinitum.
Would it not be easier to exploit this and go the "opposite" way
i.e. rather than remove it, just extend the hierarchy by adding a
base class to Object itself (in object.d no less), something like
this:
class ObjectBase
{
interface Monitor{..}
static ObjectBase factory(string classname){..}
}
class Object : ObjectBase
{
string toString(){..}
size_t toHash() @trusted nothrow{..}
int opCmp(Object o){..}
bool opEquals(Object o){..}
static Object factory(string classname){..}
}
Now, if you do:
class Foo{..} //OK. Still inherits from Object i.e. identical to
'class Foo : Object {..}
class Foo : Object {..} //The same, just explicit
//On the other hand:
class Bar : ObjectBase //Deliberately bypass inheritance from
Object.
Inheritance from ObjectBase will have to be explicit (the price
to pay for non-breakage!), but now class Bar is free to implement
opEquals, opCmp, toHash, etc as it sees fit. This still
guarantees back-wards compatibility since all classes currently
inherited from Object have exactly the same semantics as they do
today. No upgrades to any current projects/code required!
Why was something like this not considered (you don't give a
link, so I cannot investigate), rather than simply removing them
from Object? Can this be exploited to, in effect, create the same
opportunity but minus the breakage? Or am I missing something?
Actually, in a more general sense I have begun to wonder if the
common point of departure in D-land, that the concept of
tail-const is actually a "part of" the concept of const, is not
maybe wrong. We typically describe the concepts of
tail/head-const "in terms of" const i.e. const in D 'equals'
head-const 'plus' tail-const [1]. Since the concepts of
tail-const and head-const are not that well known (outside of
mostly C++-land), these 2 concepts are often utilized to
differentiate D's concept of const, and explain it relative to
the const (or final/sealed/readonly/etc) found in other
languages. Maybe that muddles the water, and the 3 concepts, even
though related, can semantically exist separately as well!
I am of the opinion that we really need something like tail-const
in D - particularly to semantically mark that the "payload" in a
range is constant, but that the range itself can mutate. But it
invariably falls apart when you try to shoehorn it into the
general concept of const-ness in D with its transitivity
properties, etc. The 2 concepts just don't gel, and I think the
only way this can be accomplished is to have a separate semantic
construct and syntax for tail-const. I think the 2 use cases are
mostly orthogonal, and only overlapping in a narrow sense - but
it this narrow sense that is used to explain it!. And, yes, the
tail-const version will have less guarantees and none of the
optimization opportunities that the current const version can
promise.
Of course I realize the changes of this being added to D is
practically zero; So, yes, i have to concur with your conclusions
as well!
PS. BTW, your blog's title "The Long-Winded D Guy" is quite
brilliant. You are indeed a bit long-winded, but you also take
the time to explain things very thoroughly. It is a trade-off and
I think in your case the cost-benefit ratio is positive. Thank
you for that! Also, if you ever write a book (it might have to
come in multiple volumes ;-), you can already count on having 1
buyer!
[1] https://dlang.org/articles/const-faq.html#const
Re: Release D 2.079.0
On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058
Re: Article: Why Const Sucks
On Monday, March 05, 2018 17:35:28 ShadoLight via Digitalmars-d-announce wrote: > Very interesting and well written! Jonathan, your experiences > with const in C++/Java just about matches my experiences with it. > I also feel that the situation in D is less than ideal in this > regard. > > First, a small (for sure copy-pasta) typo in your article: > > const(int[]) arr1 = getArray(); > const(int)[] arr2 = p1; //Sure you meant arr2 = arr1; Thanks. Fixed. > Regarding the proposed solution to the issues with Object namely > "the solution to this problem which was agreed to a few years ago > was to remove opEquals, opCmp, toHash, and toString from Object > so that derived classes can define them with whatever attributes > are desired" which, you say, will never happen because of too > much code breakage... > > What about the following? Currently the compiler is smart enough, > so you can define class Foo and explicitly inherit from Object if > you prefer: ... > Why was something like this not considered (you don't give a > link, so I cannot investigate), rather than simply removing them > from Object? Can this be exploited to, in effect, create the same > opportunity but minus the breakage? Or am I missing something? As I mentioned, there was recently some talk about creating a DIP to add a new root object below Object. If that's done, presumably, Object will still be the default to avoid code breakage, but it would be provide essentially what you're talking about. However, such a DIP still has to be written, so anything at this point is speculation as to what it's going to look like. At the time that it was decided to remove the functions from Object, it was more reasonable than it would be now (since D is definitely older now with a larger user base), and the details of how it would be done were never fully decided, which is part of why it's never come to fruition in spite of it being clear that we needed a root object without those functions. - Jonathan M Davis
Re: Article: Why Const Sucks
On Monday, March 05, 2018 09:38:52 H. S. Teoh via Digitalmars-d-announce wrote: > Eventually, I discovered > that the underlying problem was that Result, as defined above, was a > struct with a const member, and therefore it was illegal to assign it to > a variable of the same type outside of initialization (since doing do > meant you were overwriting a const field with something else, which > violates the constness of the field). This broke the by-value > assumption inherent in much of Phobos code, so the resulting range ended > being unusable with most Phobos algorithms. Which defeated the whole > purpose in the first place. Honestly, I've come to the conclusion that structs should never have const or immutable members. It just causes too many problems. Treating them as read-only from the outside by having them be private and have member functions be const is fine (assuming that const works in that case), and having them work when the entire object gets marked as const is great (assuming that const works in that case), but I think that it's pretty much always a mistake to make individual member variables of a struct const or immutable. Classes don't have the same problem, because they're on the heap and don't get copied, but with structs being on the stack and very much being designed with copying in mind, members that can't be copied becomes a definite problem. Tail-const and tail-immutable would work fine with member variables in structs, but that basically means that the data for those members has to be on the heap, which isn't always a reasonable option. > So yeah, while D's const provides actual guarantees unlike C++'s > laughable const-by-documentation, that also limits its scope so much > that in practice, it's rarely ever used outside of built-in types like > string. Which also limits the usefulness of its guarantees so much that > it's questionable whether it's actually worth the effort. Exactly. - Jonathan M Davis
Re: Article: Why Const Sucks
On Mon, Mar 05, 2018 at 11:04:49AM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Monday, March 05, 2018 09:38:52 H. S. Teoh via Digitalmars-d-announce > wrote: > > Eventually, I discovered that the underlying problem was that > > Result, as defined above, was a struct with a const member, and > > therefore it was illegal to assign it to a variable of the same type > > outside of initialization (since doing do meant you were overwriting > > a const field with something else, which violates the constness of > > the field). This broke the by-value assumption inherent in much of > > Phobos code, so the resulting range ended being unusable with most > > Phobos algorithms. Which defeated the whole purpose in the first > > place. > > Honestly, I've come to the conclusion that structs should never have > const or immutable members. It just causes too many problems. Treating > them as read-only from the outside by having them be private and have > member functions be const is fine (assuming that const works in that > case), and having them work when the entire object gets marked as > const is great (assuming that const works in that case), but I think > that it's pretty much always a mistake to make individual member > variables of a struct const or immutable. [...] Yeah, but in this case, since `this` is const, there's simply no way to get around the fact that there must be `const` somewhere in the Result struct. The D compiler will not accept a mutable member referencing `this` that has a const access method, since that in theory breaks the const guarantee. I suppose replacing `const(Container)` with tail-const references to Container's innards would fix the problem, but it would uglify the code too much and would be far too much effort just to be able to say "we support const", that it's simply not worth it. Also, structs with const/immutable members are a rare case allowed by the language but almost never tested for in Phobos, so you can pretty much expect random things to break left, right, and center if you ever attempt to use such a struct with Phobos functions. In fact, I vaguely remember that even the compiler may have bugs / strange behaviours if you try to use such structs in non-trivial ways. T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 13:48:23 UTC, Adam D. Ruppe wrote: Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement. Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words. You guys are a bunch of nerds . . . .
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 13:48:23 UTC, Adam D. Ruppe wrote: Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement. Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words. You guys are a bunch of nerds . . . . - Me
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 13:48:23 UTC, Adam D. Ruppe wrote: Just a semantic note, it is "straitjacket". "straight" is like a non-wiggly line. "strait" means narrow or constricted. Thus, the straitjacket is a jacket that constricts your movement. Of course, using "straight" is such a common mistake it has become generally accepted... but still, I like being precise with my words. Programmers like precision, don't we! From Simon Tatham article about how to report bugs effectively: https://www.chiark.greenend.org.uk/~sgtatham/bugs.html "Above all, *be precise*. Programmers like precision."
Hamburg meets D
Hello fellow Dlers, thanks to last years DConf some German D developers agreed to meet for drinks in Hamburg. With this years DConf approaching we decided (finally) on an informal get together, just beer and talking on March 29th in Hamburg. Since I am not expecting a huge run (afterall there are not many D devs in Hamburg AFAIK) I am going to host it at our companies offices at InnoGames. I am happily accepting more people, so please, if you plan on coming drop me a line here and or email me at: dilly dot stephan at gmail dot com. Currently participating: * Sönke Ludwig (+ colleague) * Martin Tschierschke * some colleagues in my team that I will convince to join ^^ * me Cheers, Stephan
Re: Hamburg meets D
On Monday, 5 March 2018 at 19:40:12 UTC, Stephan wrote: Hello fellow Dlers, thanks to last years DConf some German D developers agreed to meet for drinks in Hamburg. With this years DConf approaching we decided (finally) on an informal get together, just beer and talking on March 29th in Hamburg. Since I am not expecting a huge run (afterall there are not many D devs in Hamburg AFAIK) I am going to host it at our companies offices at InnoGames. I am happily accepting more people, so please, if you plan on coming drop me a line here and or email me at: dilly dot stephan at gmail dot com. Currently participating: * Sönke Ludwig (+ colleague) * Martin Tschierschke * some colleagues in my team that I will convince to join ^^ * me Cheers, Stephan Is this the miniDConf we were promised? :-)
Re: State of D 2018 Survey
On Sun, 2018-03-04 at 21:12 +, Kagamin via Digitalmars-d-announce wrote: > On Friday, 2 March 2018 at 12:01:33 UTC, Russel Winder wrote: > > So having D2.999 is fine per se, but advertises a lack of > > change and a lack of ambition since the language name is D not > > D2. > > D just doesn't follow semver. If it did, we would have D79 now, > nothing else even comes close to this. And I suspect it won't > adopt semver because major number would be so ridiculously high > and will advertize something else. I do not see your reasoning here. Has the core D computational model changed? I think not. Does D issue bugfix releases? Occasionally. Thus: 2.79.0 seems like a perfectly reasonable semantic version number for D. > > Fortran, C++, and Java show an obsessive adherence to backward > > compatibility and yet they increase their major numbers to give > > the appearance at least of forward progress. > > C++ and Fortran don't have version numbers, those are brand > numbers. Actually no, they are standards version numbers. Once you have an ISO standard for a programming language semantic versioning is impossible, but the standard number is the version number. On the other hand this is trivia and so shouldn't become a Big Issue™. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: LDC 1.8.0
On Monday, 5 March 2018 at 12:14:52 UTC, kinke wrote: On Monday, 5 March 2018 at 07:45:04 UTC, Johannes Loher wrote: Will there also be a armhf Release? Yep; it'll most likely be up this evening (CET). I just saw that it is up now, thats awesome, thank you very much for your efforts!
Re: Release D 2.079.0
On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote: On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058 It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila
Re: Release D 2.079.0
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production? As far as I'm concerned, every release is a beta... even if the beta tag is removed. The real problem is something you mentioned .. new comers downloading the latest release..which as I mentioned, is really a beta. But that's just the way software developement works these days - sadly - ship quickly, and ship often. As a result, we're all just testers for the latest release.
Re: Release D 2.079.0
Am 06.03.2018 um 00:40 schrieb Atila Neves: (...) This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila I tagged a RC today: https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/49899/ To avoid letting this sit broken I'll shorten the final testing phase, so that the release happens this Thursday. This is a bit unfortunate, because this release is a bit more disruptive than normal due to the switch to using vibe-core by default. So early testing with "dub upgrade --prerelease" in different projects is particularly valuable this time! BTW, the problems with this release are a strong hint that we should rethink the inclusion approach with std.experimental. Since breaking changes are tied to the DMD version, it makes those modules almost unusable outside of toy code. Having them as a DUB package (or in essence, in a separate repository) on the other hand nicely decouples them from the compiler release and makes it possible to properly version them individually.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 00:10:52 UTC, Sönke Ludwig wrote: BTW, the problems with this release are a strong hint that we should rethink the inclusion approach with std.experimental. Since breaking changes are tied to the DMD version, it makes those modules almost unusable outside of toy code. Having them as a DUB package (or in essence, in a separate repository) on the other hand nicely decouples them from the compiler release and makes it possible to properly version them individually. Additional evidence: std.experimental.ndslice -> libmir.
Re: Hamburg meets D
On Monday, 5 March 2018 at 19:40:12 UTC, Stephan wrote: Hello fellow Dlers, thanks to last years DConf some German D developers agreed to meet for drinks in Hamburg. What time?
Re: Article: Why Const Sucks
On 03/05/2018 12:38 PM, H. S. Teoh wrote: This broke the by-value assumption inherent in much of Phobos code, Wait, seriously? Phobos frequently passes ranges by value? I sincerely hope that's only true for class-based ranges and forward-ranges (and more specifically, only forward ranges where copying the range and calling .save are designed to do the exact same thing). Otherwise, that's really, *REALLY* bad since non-forward ranges *by definition* cannot be duplicated. Honestly, I think this is the one big flaw in the otherwise really nice design of ranges. The definition of "what is a forward/non-forward range" for struct-based ranges should have been "is this() @disabled (non-forward range), or is this() enabled *and* does the same thing as .save (forward range)?" Without that, this is a serious hole in non-forward ranges.
Re: mysql-native v2.1.0
On 03/05/2018 09:23 AM, aberba wrote: On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == [...] Is unix socket connection supported? I'm not seeing any information about it in the docs. It's not currently supported. From the "Additional Notes" section of the readme: "Normally, MySQL clients connect to a server on the same machine via a Unix socket on *nix systems, and through a named pipe on Windows. Neither of these conventions is currently supported. TCP is used for all connections." - https://github.com/mysql-d/mysql-native#additional-notes I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design.
Re: Release D 2.079.0
Can somebody explain how &array[0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how &array[0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. int[] a; writeln(&arr[0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
Re: State of D 2018 Survey
On Monday, 5 March 2018 at 20:52:10 UTC, Russel Winder wrote: I do not see your reasoning here. Has the core D computational model changed? I think not. Major number per semver increases when interface changes, D does it pretty often, it is the fastest moving language I know. Does D issue bugfix releases? Those are point releases. 2.79.0 seems like a perfectly reasonable semantic version number for D. It's a reasonable version number, but doesn't follow semantics of semver. You can't blindly assume that different versioning schemes advertize the same things.
Re: Article: Why Const Sucks
On Monday, March 05, 2018 22:21:47 Nick Sabalausky via Digitalmars-d- announce wrote: > On 03/05/2018 12:38 PM, H. S. Teoh wrote: > > This broke the by-value > > assumption inherent in much of Phobos code, > > Wait, seriously? Phobos frequently passes ranges by value? I sincerely > hope that's only true for class-based ranges and forward-ranges (and > more specifically, only forward ranges where copying the range and > calling .save are designed to do the exact same thing). Otherwise, > that's really, *REALLY* bad since non-forward ranges *by definition* > cannot be duplicated. > > Honestly, I think this is the one big flaw in the otherwise really nice > design of ranges. > > The definition of "what is a forward/non-forward range" for struct-based > ranges should have been "is this() @disabled (non-forward range), or is > this() enabled *and* does the same thing as .save (forward range)?" > > Without that, this is a serious hole in non-forward ranges. Passing ranges around by value is fine so long as you don't use the original after the copy is made. Where you get screwed is when you then use the original after the copy has been made. Almost nothing in Phobos passed ranges around by ref, and doing so would actually make it a royal pain to iteract with forward ranges, because save obviously isn't an lvalue, and range-based functions that return new ranges aren't returning lvalues. So, if range-based functions took their arguments by ref, then you couldn't chain them. And using auto ref wouldn't fix the problem, since you could still pass by value. It would just introduce all kinds of inconsistent behavior as to whether a range was copied or not depending on how exactly a range-based function were called, causing more bugs. Honestly, I think that the correct way to implement forward ranges would have been to disallowing ranges that weren't dynamic arrays or structs and then use postblit constructors instead of save (classes could then be used as ranges by wrapping them in structs, though even then, it would be better to avoid classes as ranges, because all of those calls to new get to be inefficent). With that, you wouldn't have all of these problems with accidentally saving or not. Any time a forward range was copied, it would be saved automatically, unless it could be moved, in which case, saving wasn't necessary. Unfortunately, that still leaves the problem of basic input ranges, since they wouldn't have postblit constructors, and they could still be defined as pseudo-reference types. Maybe we could require them to be defined as classes to force them to be full-on reference types (they obviously can't be value types, or they could be forward ranges), but then that would force allocations for basic input ranges. _Most_ ranges can be at least forward ranges, but some stuff can't reasonably be, and you wouldn't want to have to allocate all of those on the heap. So, I don't have a clean solution for how to deal with basic input ranges and copying, though I haven't sat down recently and tried to work through the problem. In principle though, they're reference types and ideally would be treated as such. Regardless, I doubt that the design of ranges is going to be changed at this point given the amount of code that would break as a result, and these sort of changes are not backwards compatible. - Jonathan M Davis
Re: Release D 2.079.0
On 3/5/18 15:40, Atila Neves wrote: On Monday, 5 March 2018 at 17:47:13 UTC, Seb wrote: On Monday, 5 March 2018 at 15:16:14 UTC, Atila Neves wrote: On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this 👏 https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Is is just me or did this release just break the latest non-beta vibe.d? Is the Jenkins build testing the dub packages on master instead of the latest tag? Atila https://github.com/vibe-d/vibe.d/issues/2058 It's great that there's an issue for vibe. This doesn't change the fact that right now, somebody trying D for the 1st time with the latest official compiler will get an error if they try out the most popular dub package that I know of if they follow the instructions on code.dlang.org. It also doesn't change that I can't upgrade dmd on our CI at work because it can't compile vibe unless I change dozens of dub.sdl files to use a beta version. This breaks semver! I found out about this after removing a dependency on stdx.data.json since dmd >= 2.078.0 broke it (by breaking taggedalgebraic. Yes, I filed a bug.). I can upgrade from 2.077.1 to 2.078.3,but not 2.079.0. I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila May I make a recommendation? Only upgrade to the 2.0xx.2[.3] releases. You'll have to wait a month or so for the latest features, but by then the important packages will have been upgraded and the regressions (mostly) worked out. It's kind of like the old saying about Microsoft software. "Never use the first version of anything". If we treat the .0 releases as "v1" then it fits. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Release D 2.079.0
On Tuesday, March 06, 2018 05:34:39 psychoticRabbit via Digitalmars-d- announce wrote: > On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: > > Can somebody explain how &array[0] is more safe than array.ptr? > > Just want to understand why second statement isn't allowed in > > safe anymore. > > int[] a; > writeln(&arr[0]); // good - runtime produces a > core.exception.RangeError > //writeln(arr.ptr); // what do you think will happen here? That example actually should be perfectly @safe, because the array is null, and it's using writeln. Dereferencing null is @safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's @safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's @safe too, even if the pointer value is garbage. The problem is when the dynamic array's ptr points to something other than null, and its length is 0. a[0] does bounds checking, so &a[0] is only valid if the dynamic array's length is greater than 0, whereas a.ptr would happily give you a value even if the array's length is 0, and in that case, it's not valid to dereference that pointer. And depending on what that pointer points to, it could corrupt memory or access invalid memory if you dereference it. So, in _most_ cases, using ptr is actually fine, but because it's not _always_ @safe, the compiler has to treat it as @system. It was previously thought to be fine, because the case where a dynamic array is empty but non-null had not been considered when deciding whether ptr could be used in @safe code. - Jonathan m Davis
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky (Abscissa) wrote: On 03/05/2018 09:23 AM, aberba wrote: On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: An all-D MySQL/MariaDB client library: https://github.com/mysql-d/mysql-native == [...] Is unix socket connection supported? I'm not seeing any information about it in the docs. It's not currently supported. From the "Additional Notes" section of the readme: "Normally, MySQL clients connect to a server on the same machine via a Unix socket on *nix systems, and through a named pipe on Windows. Neither of these conventions is currently supported. TCP is used for all connections." - https://github.com/mysql-d/mysql-native#additional-notes I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design. UNIX sockets provide a way to securely connect in an enclosed/isolated environment without exposing connection externally. This is used in my company in our microservice infrastructure on Google Cloud: we connect to our db instance using a proxy and its the recommended approach in microservices. Its a very common security practice. The default approach on Google Cloud. I would do the same for any db I want to prevent external access to. If vibe.d doesn't support it then its missing a big piece of a puzzle.
