Re: [OT] Swift removing minor features to piss me off
I think Swift is not yet stable. So if you want to use it you have to deal with language changes (D2 is stable). In a modern language ++ and -- are OK only if they return void. Otherwise they are bug-prone and allow people to write less readable code. C for() loops are powerful, but a bit too much bug prone and they encourage too much compressed code. Better to push reasonable coding standards inside the language itself. Only const function arguments looks a bit excessive in defulting-to-const language, but I think it's acceptable if you have a way to make them mutable. It seems Swift is copying several things from Rust. Perhaps Swift is going to become more popular than Rust (because Rust is more bondage&discipline, less handy because of manual memory management, more fussy, and usually fitter for system coding, unlike Swift that is more general purpose, on the other hand Rust is a bit more free than Swift now). Bear hugs, bearophile
Re: final switch and straight integers
Dominikus Dittes Scherkl: final switch makes no sense on things that are not enumerated. Even on ubyte almost nobody will ever list all 256 cases, not to mention larger types. It's easy to cover all the values in a switch, using ranges. No need to forbid final switch for integral values. It just needs to be implemented correctly. Bye, bearophile
Re: D vs Rust
gour: For quite some time I was looking at Ada as potential language to write multi-platform desktop application, but, being the big language which requires lot of time and energy to invest into learning/mastering it, I, somehow, feel reluctant seeing that there is practically no open-source community around Ada, no truly open-source compile -- what would happen if AdaCore would simply pull the plug since I do not believe there are enough people capable to maintain/develop FSF GNAT, so I'd appreciate if you can write few words about Ada vs D hoping that the latter it one you are recommending for new (gui) projects? I simply hope that D can provide me with most/all the features I'd expect from the language like Ada, but but even more modern features, more choices when it comes to developing GUI desktop app, more compiler choices, better tooling and, of course, much bigger community of open-source enthusiasts. Ada language has several nice features worth stealing (I'd like both D and Rust to add constrained values, static preconditions, ranged subtypes, and annotations to control access to global variables), and if you're writing a train control system, a space probe/satellite, a military machine control, a hardware-constrained device that needs to be very reliable (like a medical machine working inside the body) then using Ada/SPARK could be reasonable. But for an average multi-platform desktop application Ada is not a good idea. The main problem is not the language itself (that is very verbose, but that's not a show-stopper), but the tooling (very scarce, and very pricey, very few compilers, very few IDEs, etc), the community (small), and the libraries (not many). A sufficiently rich and sufficiently determined group of programmers could probably write a regular desktop application in Ada, but you're walking uphill for not enough reason. Sometimes worse is better because it's actually overall better. There is a recent thread about Ada on Reddit, but unfortunately the best comment in that page has being deleted... :-) https://www.reddit.com/r/programming/comments/49y7sc/11_myths_about_ada/ Bye, bearophile
Re: D vs Rust
xenon325: Doesn't http://wiki.dlang.org/DIP25 fix this ? I think DIP25 is designed to be only a partial solution, it's not a complete memory safety story. Bye, bearophile
Re: D vs Rust
On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
Guillaume Piolat
"- D is a large language, not sure how much relatively to Rust.
I've heard Rust is complicated too."
and yet, it's easy to get started if you know C. one can be
quite quickly productive without having any experience of
template metaprogramming, CTFE, and the like, and gradually
absorb language features as you go. Phobos is pretty readable,
on the whole. I agree with bearophile about GC making it
easier in the beginning.
bearophile:
"I am sometimes able to write working D code almost as quickly
as Python code"
Yes, indeed - that's my experience too. I wonder what we could
do to make this most of the time, if not almost always, and for
less experienced programmers than you. It wouldn't be
surprising to find that the things that tend to get in the way
fall in certain common categories. Some people have applied
machine learning to compilers to study this - that's probably
beyond our resources for now, but the idea makes sense. Adam's
and others' work on error messages might be part of the answer.
Thank you for the colour on OcaML. What could be done to
improve Algebraic and pattern matching? The talk at the London
dmeetup was quite interesting, but I had the sense that was
fairly experimental at this stage.
"There are several kinds of code that D allows you to write
quite better than Rust (generic application code, script-like
code, explorative scientific numerical code (like ndslice),
medium-integrity code, metaprogramming, compile-time
computations, template-level computations and specializations,
higher order template magic, and so on. "
Should we make more of a feature of this in the intro page.
Tutorials per category showing the value? And should the
Rosetta stone examples (many of which you wrote, as I
understand it) be more prominently featured? Maybe even in the
code samples on the front page too.
"In Ada you can be productive if you use it for the purposes it
was invented for, but most times you don't write that kind of
code."
Thank you - yes that's what I figured, and it probably isn't
for me. But I wanted to see if I was missing something.
" I like languages that avoid me most common bugs,"
I wonder what the most common bugs and traps are in D. P0nce's
D idioms allude to some of them, but that isn't the focus of
what he writes.
"I think D should relax and keep improving its strengths (like
C++ interoperability), fix some of its holes (safety, GC-less
programming, fixing its contract-driven programming experience,
etc), improve its medium-integrity coding, and keep going on as
usual, slowly getting better. The Rust and D niches are
sufficiently different, there's minimal overlapping in their
purposes and niches."
Yes - I completely agree. As Peter Thiel says, competition is
for losers. Much better to have a monopoly that you have
earned (and have to keep earning). I agree with Knuth that
language reflects thought and people intrinsically think
differently (this also being shaped by the domain) - he
welcomed the prospect of an expansion in the number and kinds
of language available.
It's funny how the most negative critics in this forum and who
make diffuse statements about how D has lost the race often
don't seem to contribute much code to making things better.
Contrast with Manu, for example, who whilst spirited is
actually through actually using the language and reporting
concrete difficulties is directly driving the completion of
some features.
Walter - sorry about that. I need to get someone to help on
that front as I have so little time. Should work now.
Laeeth
Guillaume Piolat:
What could be done to improve Algebraic and pattern matching?<
The number of developers working on D compiler, D design and
Phobos is limited, and D is a large language. So it's better to
focus the developing work on fixing and finishing the unfinished
parts of D, instead of adding new ways to do the same things.
And even if you want new D features, there are more important
things to think about, like GC-less coding, C++ interoperability,
async/await, and so on.
I wonder what the most common bugs and traps are in D.<
You have to take care of the less common bugs too if you want a
reliable language.
And currently it's dead-easy to write unsafe code even in @safe D
functions:
int[] foo() pure @safe {
int[2] a = [10, 20];
auto b = a[];
return b;
}
void main() {}
Now that Rust is showing some "intellectual" competition with
C++, Stroustrup is even starting to think about adding some
memory safety to C++ (but it's hard for this to become a complete
memory safety for C++):
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines
Regarding the code reliability, D is better than C++11, but it
can be further improved, as Ada2012/SPARK show. On the other
hand, a higher reliability has a c
Re: D vs Rust
Laeeth Isharc: On Saturday, 30 January 2016 at 16:51:09 UTC, Laeeth Isharc wrote: I haven't used Ocaml, but was intrigued by it after seeing Yaron Minsky's talks. To what extent can pattern matching, strong types with invariants and other things Ocaml features be implemented idiomatically in D? Eg I know D has invariants, but that seems to be more a debug mode thing, and I am not sure if they are doing the same as what Minsky described in his talk. Rust allows you to write very OCaML-like code, the main difference is that you need to memory manage manually (and Rust doesn't have a GIL). D Algebraic isn't very good, and the D/Phobos pattern matching is minimal, so to write compiler-like code in D you need a style quite different from the OcaML/F#/SML/Haskell code. On the other hand Rust is less flexible, sometimes even C-like for loops are not handy to do in Rust. The Servo browser and the Rustc compiler are two of the main projects written in Rust, so sometimes Rust looks like a browswer-driven language, and this means Rust developers sometimes seem to not understand or not care that lot of people have other different needs. There are several kinds of code that D allows you to write quite better than Rust (generic application code, script-like code, explorative scientific numerical code (like ndslice), medium-integrity code, metaprogramming, compile-time computations, template-level computations and specializations, higher order template magic, and so on. In general Rust seems a more specialized language). How productive do you find coding in Ada ? In Ada you can be productive if you use it for the purposes it was invented for, but most times you don't write that kind of code. I miss some Ada features, and I've missed the strictness of the Ada compiler that catches lot of bugs, but for most things today I prefer a more modern languages. In Ada you need more time to write the code and make it run, but later you save some debugging time, even compared to D. I like languages that avoid me most common bugs, even if I need more time to write it. To write Ada code you need to remember lot of times, because Ada is a quite large language, but most things are quite logical and straightforward, so learning Ada is just a matter of having elephant's memory, you don't need to be smart. Rust is a much smaller language, but you need to think more about your code, otherwise it will never compile :-) D is more like Python, you don't need lot of memory to use it, and the garbage collector saves you lot of thinking (if you are writing small programs). I think D should relax and keep improving its strengths (like C++ interoperability), fix some of its holes (safety, GC-less programming, fixing its contract-driven programming experience, etc), improve its medium-integrity coding, and keep going on as usual, slowly getting better. The Rust and D niches are sufficiently different, there's minimal overlapping in their purposes and niches. Bye, bearophile
Re: D vs Rust
qznc: On Friday, 29 January 2016 at 09:00:52 UTC, qznc wrote: D is a broader language and is applicable in more situations. In many cases you don't care and don't want to care about memory management. Learning to manage memory in Rust takes lot of time and practice, it's a bit painful. I am sometimes able to write working D code almost as quickly as Python code, but writing similar code in Rust takes me much more time. So I think for both small script-like programs, and general application code (where code safety is not the most important thing), D wins over Rust. D is also more flexible (higher order templates, better CTFE, unrestricted UFCS, etc), and you can port Python or C code to D faster than to Rust. So I think Rust targets a smaller number of coding purposes compared to D. Rust could also replace the code you want to write in OcaML, like compiler-like programs (thanks to Rust enums and pattern matching). Safety and correctness of the code are very important for me. Regarding safety & correctness I think there's this ordering: Rust > D > C++14 > C If you talk about correctness you think about Ada too. Rust code seems usually more succinct compared to Ada code. Ada is more mature and it has lot of small features missing from Rust/D, that help make the code more correct (like integer subsets, static invariants, stronger typing for array indexing, SPARK annotations to manage global mutables safely, and so on). I don't know if such safety features will be added to Rust, I am dubious. In the C/Ada world you have language subsets like MISRA/SPARK that people use in high integrity system. I think Rust still lacks something like that. Bye, bearophile
Re: Under 1000 opened bugs for Phobos
BBaz: So I don't know...and I ask, should the garbages from bearophile be closed ? Hello, I use D every day, and there are several functions that I'd like in Phobos. I think all/most of them can be of general usefulness. While I am often wrong, those ERs come from plenty of experience coding in D and other languages, so throwing them away *en masse* is unwise. They should be judged singularly. Bye, bearophile
Re: a "success story for D" ! !!
ponce: Paper: http://vlang.org/dvcon2014.pdf I'd say that's pretty huge! Very nice. Bye, bearophile
Re: if(arr) now a warning
Andrei Alexandrescu: I have no doubt the change can find certain errors. Problem is false positives. FWIW these are the changes I had to operate on std.allocator to make it work with the new compiler. One per 194 lines on average, all false positives: Just fix your code Andrei Alexandrescu :-) Bye, bearophile
Re: [hackathon] An article about metaprogramming
Mafi:
https://marfisc.wordpress.com/2015/04/29/using-d-templates-for-gamedev/
What do you think? Any remarks?
The SDL_Event is a union. Accessing it is inherently unsafe for
type consistency and memory safety. The SDL library mitigates
this problem by adding a tag (the member type) which encodes
which union-member is to be used.<
In Rust you use the built-in tagged unions and call it a day...
switch(polledEvent.type) {
mixin(caseOnEvent!("SDL_QUIT", "quit"));
mixin(caseOnEvent!("SDL_ACTIVEEVEENT", "active"));
mixin(caseOnEvent!("SDL_KEYDOWN", "eventKeyDown")); // (*)
mixin(caseOnEvent!("SDL_KEYUP", "eventKeyUp")); // (*)
mixin(caseOnEvent!("SDL_MOUSEMOTION", "motion"));
mixin(caseOnEvent!("SDL_MOUSEBUTTONUP",
"eventMouseButtonUp")); // (*)
mixin(caseOnEvent!("SDL_MOUSEBUTTONDOWN",
"eventMouseButtonDown")); // (*)
mixin(caseOnEvent!("SDL_JOYAXISMOTION", "jaxis"));
mixin(caseOnEvent!("SDL_JOYBALLMOTION", "jball"));
mixin(caseOnEvent!("SDL_JOYHATMOTION", "jhat"));
mixin(caseOnEvent!("SDL_JOYBUTTONDOWN",
"eventJoyButtonDown")); // (*)
mixin(caseOnEvent!("SDL_JOYBUTTONUP", "eventJoyButtonUp"));
// (*)
mixin(caseOnEvent!("SDL_USEREVENT", "user"));
mixin(caseOnEvent!("SDL_SYSWMEVENT", "syswm"));
default: //has to be there even if empty
static if(is(typeof(that.onOther(Event.init {
that.onOther(polledEvent); break;
}
}
The default should be aligned just like the other cases. Often is
a good idea to use "final switch" with enumerations.
Probably there are ways to make that code more dry, using a
TypeTuple of pairs like ("SDL_QUIT", "quit").
Bye,
bearophile
Re: if(arr) now a warning
Steven Schveighoffer: FYI, Andrei and Walter are reversing this change barring any new evidence it's helpful to people. Please speak up if you disagree. There's no more evidence. It's an improvement, for people coming from Python. The current semantics is not meaningful. One of the points of D over C++ was to fix irrationally designed parts, like this small problem. Many small design mistakes like this one create C++ we know and hate. We should fix such small problems quickly and look forward, instead of debating forever and reverting every small step forward like this. My presence around here is becoming useless. Bye, bearophile
Re: C++ const expression are not that const after all
Luc Bourhis: The author of that blog seems to see his finding in a positive light actually. As it makes it possible to write more powerful template metaprograms! One of the essences of modern languages is to restrict the power of the programmer in specific parts, to reduce unwanted interactions and make complexity more manageable. His finding seems a design mistake. Bye, bearophile
Re: switch case expressions
Martin Krejcirik: So, should the case b compile or not ? Is the spec too restrictive here, or is it a bug ? Apparently it's a WONTFIX mess. The spec should be updated. Walter&Andrei refused to fix a design bug here. Bye, bearophile
Re: Cleaned up C++
Walter Bright: On 4/22/2015 2:58 PM, bearophile wrote: D is less stack-friendly than Ada (and probably Rust too), ?? In Ada standard library you have safe fixed-size stack-allocated associative arrays. In D you can't even allocate safely a dynamically-sized 1D array on the stack, and forget about doing it for 2D. Enough said. Bye, bearophile
Re: Cleaned up C++
weaselcat: On Wednesday, 22 April 2015 at 19:29:08 UTC, Walter Bright wrote: D is just another of those “Let's put everything on the heap”-languages that do then of course need GC. what's up with people constantly equating garbage collection to being the same as java? In D you don't put everything on the heap. D is less stack-friendly than Ada (and probably Rust too), but in D you allocate lot of small stuff on the stack. Bye, bearophile
Re: Vectorization examples
Walter Bright: Use arrays of double2, float4, int4, etc., declared in core.simd. Those will be aligned appropriately. Is the GC able to give memory aligned to 32 bytes for new architectures with 512 bits wide SIMD? and a way to tell the type system that some array slices are fully distinct (the __restrict seen here, I think this information doesn't need to be part of a type). A runtime test is sufficient. One of the points of having a type system is to rule out certain classes of bugs caused by programmers. The compiler could use the type system to add those runtime tests where needed. And even better sometimes is to avoid the time used by run time tests, as shown in that video, using the static information inserted in the code (he shows assembly code that contains run time tests). Another example of missing static information in D is shown near the end of the video, where he shows an annotation to compile functions for different CPUs, where the compiler updates function pointers inside the binary according to the CPU you are using, making the code safe and efficient. Bye, bearophile
Vectorization examples
"Utilizing the other 80% of your system's performance: Starting with Vectorization" by Ulrich Drepper: https://www.youtube.com/watch?v=DXPfE2jGqg0 It shows two still missing parts of the D type system: a way to define strongly typed byte alignments for arrays (something better than the aligned() shown here, because I prefer the alignment to be part of the type), and a way to tell the type system that some array slices are fully distinct (the __restrict seen here, I think this information doesn't need to be part of a type). Bye, bearophile
Re: D vs nim
Russel Winder: it is all part of guerilla marketing undertaken by anyone with anything to market. It's still not a correct behavour, regardless how many do it. Bye, bearophile
Re: How about appender.put() with var args?
Márcio Martins:
app.put("foo");
app.put(var);
app.put("bar");
I'd like put() to accept a lazy range...
Bye,
bearophile
Re: Does 'D' language supports 'C' like VLA?
John Colvin: The problem is that the size isn't necessarily known. The size is generally known only at run-time, that's the point. I guess the compiler could put in a branch, but at that point you'd probably want to give the programmer control and have a way of making it explicit. You don't forget to put branches added by the compiler, so it's safer. Generally you prefer something that's guaranteed to be allocated on the stack when it's small and there's enough stack. An array allocation annotated with "scope", perhaps. Bye, bearophile
Re: Programming languages and performance
weaselcat: It's reddit, that's not really surprising. Do you know a place better than Reddit for general programming discussions? The lambda the ultimate blog is not generic. Bye, bearophile
Re: Programming languages and performance
Walter Bright: Algorithms don't actually do deforestation or fusion. The magic happens in how the algorithm is implemented, i.e. the elements are created lazily (on demand) rather than eagerly. Stream fusion is often about laziness. There is a ton of literature about this topic. Bye, bearophile
Re: Does 'D' language supports 'C' like VLA?
Steven Schveighoffer: It's very unlikely this will make it into the language. Alloca should be good enough for this, it's not a very common usage, and supporting it is not easy. alloca is bug-prone and unsafe, and if you want to create a 2D array on the stack it's not good enough. They are uncommonly used because they are not supported by the D compiler, and it doesn't track the memory ownership well enough. But a well designed system language needs to push programmers to use the stack as much as possible. Bye, bearophile
Re: DIP77 - Fix unsafe RC pass by 'ref'
Marc Schütz: You have to keep in mind that this is opt-in; it only applies to `scope` variables. I would agree that as a default, it wouldn't fit D at all. I think that, for all its usefulness, it'd be a tad too limiting for my taste if I were forced to use it everywhere. I think D Zen asks for safety on default and opt-out on request. See also "@safe by default": https://issues.dlang.org/show_bug.cgi?id=13838 Bye, bearophile
Re: if(arr) now a warning
Steven Schveighoffer: What do you think? I asked for this fix almost five years ago, so I think it's about time :-) Bye, bearophile
Re: Why I'm Excited about D
deadalnix:
foreach (name; names.parallel) {
name.writeln;
}
no.please
I think "foo.writeln;" is acceptable. You just need to get a bit
used to it.
Bye,
bearophile
Re: Fun project - faster associative array algorithm
Andrei Alexandrescu: A possible cache-friendly replacement would be an array of buckets with local probing to resolve collisions. Arrays would need to move data. Current hashtables rely on values staying put. -- Andrei The efficiency behavour of modern CPUs+memory pyramid are rather not linear and not intuitive. As Walter has said at the the start of this thread, arrays come out as more efficient in a large number of cases... Bye, bearophile
Re: Fun project - faster associative array algorithm
w0rp: It doesn't amaze me at the moment, as it's slightly faster for integers, and slightly slower for strings at the moment. One problem with D strings is that they don't cache their hash value. Bye, bearophile
Re: DIP76: Autodecode Should Not Throw
Vladimir Panteleev: std.conv doesn't return NaN if you try to convert "banana" to a double. I have suggested to add a nothrow function like "maybeTo" that returns a Nullable result. Bye, bearophile
Re: Questions about phobos additions mentioned in 2015H1 vision document
Andrei Alexandrescu: 1. Are you wanting a large "batteries included" standard library a'la Python[2] or only focused around the aspects mentioned? Batteries included. This is a quite significant decision. It has both advantages and disadvantages. (I think Rust has chosen to have a lighter std lib). Bye, bearophile
Re: The next iteration of scope
Walter Bright: I'm not convinced of the need for overloading on 'scope'. Do you want to explain some of the advantages and disadvantages of that? It will help understand your reasons. Bye, bearophile
Re: Benchmark of D against other languages
Martin Nowak: Your persistent interest in integer overflow checks make we wonder if you were responsible for this? http://www.around.com/ariane.html I am not responsible for that, but I try to not be responsible for future molecular biology mistakes equivalent to that Ariane fiasco. Bye, bearophile
Re: Benchmark of D against other languages
weaselcat:
was it a conscious decision to make the AA [] operator not
work like map/etc in C++?
What do you mean?
accessing a non-existing element in C++'s map/unordered_map
inserts the default instead of raising an exception
int main(int argc, char *argv[])
{
std::unordered_map test;
std::cout << test["hello"] << std::endl;
return 0;
}
prints 0
void main()
{
int[string] test;
writeln(test["hello"]);
}
core.exception.RangeError@source/main.d(9): Range violation
Yes, it was a conscious decision, because here C++ behaves in a
very bug-prone way. Sometimes C++ is a bad example to follow
(like with permutations generations, that currently is not a
Range in Phobos for the wrong reasons).
Bye,
bearophile
Re: Benchmark of D against other languages
Martin Nowak:
GCC5 comes with a big announcement about devirtualization.
https://www.gnu.org/software/gcc/gcc-5/changes.html#general
I have a small question. That page says:
"
A new set of built-in functions for arithmetics with overflow
checking has been added: __builtin_add_overflow,
__builtin_sub_overflow and __builtin_mul_overflow and for
compatibility with clang also other variants. These builtins have
two integral arguments (which don't need to have the same type),
the arguments are extended to infinite precision signed type, +,
- or * is performed on those, and the result is stored in an
integer variable pointed to by the last argument. If the stored
value is equal to the infinite precision result, the built-in
functions return false, otherwise true. The type of the integer
variable that will hold the result can be different from the
types of the first two arguments. The following snippet
demonstrates how this can be used in computing the size for the
calloc function:
void *
calloc (size_t x, size_t y)
{
size_t sz;
if (__builtin_mul_overflow (x, y, &sz))
return NULL;
void *ret = malloc (sz);
if (ret) memset (res, 0, sz);
return ret;
}
On e.g. i?86 or x86-64 the above will result in a mul instruction
followed by a jump on overflow.
"
Now both GCC and Clang have intrinsics to perform safe integral
operations.
In recent versions of druntime/dmd there are functions to perform
some safe integer operations. So is the API very well compatible
with those intrinsics?
Bye,
bearophile
Re: The next iteration of scope
Walter Bright: I'm thinking of a modest step which would be a subset of your proposal: 1. implement 'scope' and 'return' for arrays, classes, and pointers 2. implement inference for templates and lambdas 3. enable it with the -dip25 switch and see how far that takes us. This is interesting. For the final D programmer what's the practical difference between your proposed subset compared to the full proposal? Bye, bearophile
Re: Benchmark of D against other languages
Andrei Alexandrescu: Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei Yes, the right default for D language should be final, because lot of programmers are lazy and they don't add attributes. Bye, bearophile
Re: Adding sets to the language.
w0rp: Every now and then I want a set type, I think you can implement good enough sets in Phobos, do you agree? But you can't do the same with tuples. So I prefer sets in Phobos and tuples in the language. Bye, bearophile
Re: Why dont dlang check NullPointer?
zhmt: In short words, I want to catch something like NullPointerException. Is this possible? One solution is to add null tests to D in nonrelease mode. A better solution is to modify D to remove all or most chances of dereferencing null pointers and class references. Bye, bearophile
Re: [Phobos] You're crippled by your orthodoxism
Jean pierre: This is a problem, you, the D core has: you're crippled by your orthodoxism. Nothing will be added because of this: **rules**. The current level of acceptance of Phobos patches seems roughly correct to me. Bye, bearophile
Re: uniform tuple syntax
Vlad Levenfeld: Anything going on with this? Been looking forward to seeing it for awhile. It will happen. Bye, bearophile
Re: dfmt options
Jacob Carlborg: Although I would like that the D syntax allowed to drop the curly braces, like with if-satements. That would result in much nicer one-liner functions. See: https://issues.dlang.org/show_bug.cgi?id=7176 Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: You may want to answer there, not here. I've also posted a response. There is this, with an attach: https://issues.dlang.org/show_bug.cgi?id=11810 Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
CraigDillabaugh: You said that "Unfortunately" this thinking is going out of style "for good reasons". I am confused (sorry, I am at work, and didn't have time to watch the 1+ hour video you linked to - I said "unfortunately" because it's another reason for us to refactor and change our coding habits :-) maybe some clues were there)! Of course. I often find myself feeling a bit like Elazar. Not long ago I wrote some Python code using a bunch of the functional style programming tools and I was very please with the very concise code I had generated. Then, I had to make some modifications to the code. It took me an inordinate amount of time just to figure out what the code was doing, and I had written it myself just a few days earlier! There's not a single correct answer to this. Replacing long bug-prone explicit-loops code with pre-made safer algorithms is often a good idea. The effort of learning some very generic and reusable functions is usually worth it. But I've also seen plenty of Haskell code that requires you to know tens of tiny functions, often named with symbols like !<>!. This is worse than writing for loops. High level constructs in D are often slower than low-level code, so in some cases you don't want to use them. So as usually you have to choose wisely, because most solutions aren't perfect if you use them everywhere, there are many ways to write bad code if you don't keep your eyes and brain switched on. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Elazar Leibovich:
I personally, would have no idea what this piece of code is
doing upon first sight. I'll have to look at the documentation
of
at least two functions to understand that, and I'll have to
think carefully about what and who would throw in case of an
error.
Something like
while (n != EOF) {
n = read(fd, buf, sizeof(buf));
if (n==-1) throw(...);
if (strcmp(buf, PREFIX) == 0) {
return buf;
}
}
return NULL;
Requires no prior knowledge, and have similar effect.
I'd rather have a loop written by hand in my production code
any day, so that when debugging it, and reading it I'll have
easier time
to understand it, even though it would cost me a few more lines
when writing the code.
Unfortunately your thinking is mostly obsolete, the programming
world (well, most of it, Go is one exception) is going in the
opposite direction, and for good reasons. An explanation:
https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning
Bye,
bearophile
Re: Replace core language HexStrings with library entity
Baz: https://github.com/D-Programming-Language/phobos/pull/3058 I suggest to replace "litteral" with "literal", as in computer science: http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 Bye, bearophile
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu: That opens the question whether we want only ubyte[] for hex bytes or all integral types. I suggest to implement only ubyte[] first. And wait for enhancement requests. Bye, bearophile
Re: The next iteration of scope
Marc Schütz: Here's the new version of my scope proposal: http://wiki.dlang.org/User:Schuetzm/scope2 Let's see what Andrei and Walter think about this all :-) Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
ninja: 2. Please stop changing the (core) language all the time. There are like 3 new proposals every week in the forums and at least 2 of those are seriously considered. Please, just stop. D is not yet finished. Ownership of memory in D is a work-in-progress. Tuples are a hole in a language that wants to be a little functional. Alternative ways to allocate memory are needed by some people. The GC needs improvements. Purity is not yet finished. And there are minor things that can be improved. D3 is not planned, so the only way is to improve D2. Bye, bearophile
Re: Replace core language HexStrings with library entity
Andrei Alexandrescu: hexString and hexBytes. -- Andrei Can you show me one or two different use cases of hexString? Bye, bearophile
Re: Replace core language HexStrings with library entity
Walter Bright: Unfortunately, it needs to be a dropin replacement for x"...", which returns a string/wstring/dstring. This is bad. 99% of the times you don't want a string/wstring/dstring out of a hex string: https://issues.dlang.org/show_bug.cgi?id=10454 https://issues.dlang.org/show_bug.cgi?id=5909 Bye, bearophile
Re: Replace core language HexStrings with library entity
Marc Schütz: Can we make it so it returns a ubyte[]? There is an enhancement request on this (for the built in hex strings). Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Walter Bright: I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are. I prefer to get rid of /* */ instead :-) Because /++/ can do things /**/ can't. Bye, bearophile
Template constraints
Observe: https://github.com/D-Programming-Language/phobos/pull/3054 Is this change the partial proof of another failure of a part of D language design? What's the point of template constraints? Aren't C++ Concepts better? Or to rephrase that in a less trollish way, can D be enhanced to add user-defined error messages to template constraints, and is such enhancement a good idea? Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Paolo Invernizzi: I'm the only one so old, that for me, studying a language from a book is the normal pattern to follow for learning it? I think it's also a matter of how you usually learn. If you are a person that loves nonfinction books a lot, that reads nonfinction books a lot, then probably you also like to read a language with the help of a book. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Russel Winder: (*) IPython grew out of Python and become the de facto system, but was a mess structurally. IPython is splitting into IPython the original thing and Jupyter all the UI related stuff Jupyter looks like a nice idea and a nice project. I'd like to understand how Jupyter compared to Sage. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Walter Bright:
On 3/13/2015 3:34 AM, bearophile wrote:
"Strict mode" is a D2 with immutable+@safe+pure by default,
Thank you Walter for giving me an actual answer :-)
Note that you can get this largely by starting a module with
the following:
immutable @safe pure:
"immutable" in my post was mostly referring to local variables,
foreach variables and so on.
something like a "var" keyword to denote mutable values,
Transitive const may make this problematic.
I don't understand, but perhaps you misunderstood me. I am
talking about variables. In strict mode they are constant by
default. This means in this code both x and y are immutable:
auto x = 10;
foreach (y; 0 .. 10) {}
So in strict mode if you want them mutable you need a new keyword
like "var":
var x = 10;
foreach (var y; 0 .. 10) {}
static full tracking of memory ownership,
Makes the language significantly more complex.
You are probably right. But it also gives good things back to a
system language.
In the last years I've seen that taking twice the time to write
my code is a good deal if later I can avoid wasting stressful
hours searching and fixing bugs. So now I am willing to pay a
high price up front when I code to avoid some bugs later. I have
friends that have taken a look at Rust and have dismissed it for
being too much fussy and hard to get code to compile (despite
probably with practice the Rust rules should become quite simpler
to follow), but Rust looks like the right language for me and I'd
like the same qualities in the language that I like more (D). So
in the end I don't know what's the best solution for D.
less implicit casts (because now we have the safe int(x)
sytnax),
I think D does very well with implicit casts.
I am not sure of that. Implicit casts cause some troubles, you
can see this if you program for a while in a language with no or
with very little implicit casts like Haskell, and F#.
In D we have some implicit casts also because the "cast(int)x"
syntax is dangerous. But now we can write safe casts with the
"int(x)" syntax, so there's less need of naked implicit casts.
And I'd still like built-in tuple syntax in D.
[... Just one more feature ...] is the road to hell.
It's one more feature, and probably if D will last ten more years
other features will be added to D.
Built-in tuples have a mostly intuitive semantics, and they help
de-clutter the code. So the language gets a little more complex,
but the code becomes a little simpler.
Bye,
bearophile
Re: A few notes on choosing between Go and D for a quick project
Florin Mihaila: This note is getting too long, so if some of what I wrote needs more clarification, feel free to ask. I'm glad my humble notes are sparking discussion, and I hope D continues to grow. Constructive notes (as yours) are always welcome in this friendly community. Thank you for your help. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: That's a rather random collection - "strict" seems to be "D without the stuff bearophile dislikes". -- Andrei I am OK with that definition. Is that your best critique to those suggestions? :-) Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Ola Fosheim Grøstad: Yes, but what is a "strict mode". I agree with most of what is said about D and Go in the top post, but is there a market for yet another high level language that isn't high level enough? "Strict mode" is a D2 with immutable+@safe+pure by default, something like a "var" keyword to denote mutable values, no comma operator, static full tracking of memory ownership, less implicit casts (because now we have the safe int(x) sytnax), and few other small changes that make the language less bug prone and more strict. And I'd still like built-in tuple syntax in D. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: ## some or all of @safe, immutable, pure should be the default +1 I have a ER on @safe by default and Walter seems to agree. But I'd like more. A "strict D" mode? :-) # libraries, projects should be prominently listed and nurtured # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? ## generics? ## interoperability with C and C++? ## focus on one! D can't be a single-purpose language. And it has more moving parts compared to Go. Bye, bearophile
Re: Parallel Merge Sort
Ali Çehreli: I think there is bug in the algorithm: auto a = [90, 50, 33, 72, 35]; a.mergeSort; assert(a == [33, 50, 72, 90, 35]);// Incorrect ordering :( I translated that D code from C code of Wikipedia in few minutes, the probability of mistakes is high. Better to use some more reliable code then... Bye, bearophile
Re: Parallel Merge Sort
Josh: swap(A, B) what exactly is this doing? You should learn to answer your own questions in many cases. Take a look at the source code of Phobos, you will see the swap() implementation inside std.algorithm. It swaps the content of two values. Here the values are the structs that contain the pointer+length of the dynamic arrays. Bye, bearophile
Re: RCArray is unsafe
Walter Bright: How do you type an an array of pointers with different owners? "Sound" doesn't mean it should be able to do everything. It will be just an approximated model. It means it's going to forbid some valid code, just like every type system. You use some @system code to work around some of those limitations. And if the design is good, such islands of unsafety are located inside Phobos constructs that leak (http://en.wikipedia.org/wiki/Leaky_abstraction ) very little. Bye, bearophile
Re: RCArray is unsafe
Walter Bright: The complexity of a free list doesn't remotely compare to that of adding an ownership system. A sound complete ownership system is the only good enough solution for D. That's my opinion. Bye, bearophile
Re: Parallel Merge Sort
Josh wrote:
How can I make my parallel code more efficient. Currently, I am
getting destroyed by the serial merge sort.
http://pastebin.com/M0GKfTTX
That serial merge sort I've written is little more than a toy. I
suggest you to compare your parallel sort with a serial sort that
allocates better. Perhaps later I'll add it.
Here I have done a quick translation of some C code from
Wikipedia, this is wasteful for memory (not tested much!):
import std.stdio, std.algorithm;
/// A has the items to sort, array B is a work array.
void mergeSort(T)(T[] A) pure nothrow @safe
out {
assert(A.isSorted);
} body {
static void bottomUpMerge(T)(in T[] A, in size_t iLeft, in
size_t iRight, in size_t iEnd, T[] B)
pure nothrow @safe @nogc {
size_t i0 = iLeft;
size_t i1 = iRight;
// While there are elements in the left or right runs.
for (size_t j = iLeft; j < iEnd; j++) {
// If left run head exists and is <= existing right
run head.
if (i0 < iRight && (i1 >= iEnd || A[i0] <= A[i1])) {
B[j] = A[i0];
i0++;
} else {
B[j] = A[i1];
i1++;
}
}
}
immutable n = A.length;
auto B = new T[n];
// Each 1-element run in A is already "sorted".
// Make successively longer sorted runs of length 2, 4, 8,
16... until whole array is sorted.
for (size_t width = 1; width < n; width = 2 * width) {
// Array A is full of runs of length width.
for (size_t i = 0; i < n; i = i + 2 * width) {
// Merge two runs: A[i:i+width-1] and
A[i+width:i+2*width-1] to B[]
// or copy A[i:n-1] to B[] ( if(i+width >= n) ).
bottomUpMerge(A, i, min(i + width, n), min(i + 2 *
width, n), B);
}
// Now work array B is full of runs of length 2*width.
swap(A, B);
}
}
void main() {
auto a = [3,1,2,5,4,8,6,7,2,9,1,4,3];
a.mergeSort;
a.writeln;
}
Bye,
bearophile
Re: DIP74: Reference Counted Class Objects
Jacob Carlborg:
@arc class Foo
{
T1 opAddRef();
T2 opRelease();
}
...
Alternative A gives a clear documentation it's a reference
counted class without having to scan the methods.
Assuming you want something like DIP74, this design design seems
safer than the design proposed in DIP74.
Bye,
bearophile
Re: Contradictory justification for status quo
Walter Bright: Actually, Kenji fearlessly deals with some of the hardest bugs in the compiler that require a deep understanding of how the compiler works and how it is supposed to work. He rarely does trivia. I regard Kenji's contributions as invaluable to the community. But my point was that probably there are even better things that Kenji can do in part of the time he works on D. Bye, bearophile
Re: Contradictory justification for status quo
Andrei Alexandrescu: I'm following with interest the discussion "My Reference Safety System (DIP???)". Right now it looks like a lot of work - a long opener, subsequent refinements, good discussion. It also seems just that - there's work but there's no edge to it yet; right now a DIP along those ideas is more likely to be rejected than approved. But I certainly hope something good will come out of it. The second scope proposal looks simpler than the first: http://wiki.dlang.org/User:Schuetzm/scope2 Later in Rust they have added some lifetime inference to reduce the annotation burden in many cases. Bye, bearophile
Re: Contradictory justification for status quo
Zach the Mystic: You can see exactly how D works by looking at how Kenji spends his time. For a while he's only been fixing ICEs and other little bugs which he knows for certain will be accepted. I agree that probably there are often better ways to use Kenji time for the development of D. Bye, bearophile
Re: What am I doing wrong here - canFind with iota is not working
immutable float item = 0.174531f;
r.canFind!q{ feqrel(cast()a, cast()b) >= 21 }(item).writeln;
}
With a recent Phobos bug fix you can now write:
r.canFind!q{ feqrel(a, b) >= 21 }(item).writeln;
Bye,
bearophile
Re: Contradictory justification for status quo
Andrei Alexandrescu: Safety is good to have, and the simple litmus test is if you slap @safe: at the top of all modules and you use no @trusted (or of course use it correctly), you should have memory safety, guaranteed. I have suggested to switch to @safe by default: https://issues.dlang.org/show_bug.cgi?id=13838 Bye, bearophile
Re: DIP74: Reference Counted Class Objects
Andrei Alexandrescu: The compiler detects automatically and treats specially all classes and interfaces that define the following two methods:< Defining only one of those methods needs to give a compile-time error. This lowering assumes left-to-right evaluation of function parameters.< Is this currently enforced in all D compilers? This DIP allows defining reference counted class objects that are usable in @safe code. However, it does not enforce safety.< And do you plan to later design what's needed to enforce their safety? Bye, bearophile
Re: What am I doing wrong here - canFind with iota is not working
Laeeth Isharc:
Ie I think people diagnosed the problem, but what is the
solution...
A possible solution:
void main() @safe {
import std.stdio, std.range, std.algorithm, std.math;
immutable float oneDegree = (PI / 180.0f);
immutable float first = -(oneDegree * 10.0f);
immutable float second = (oneDegree * 10.0f);
immutable float step = 0.01f;
immutable float[] r = iota(first, second, step).array;
//r.writeln;
immutable float item = 0.174531f;
r.canFind!q{ feqrel(cast()a, cast()b) >= 21 }(item).writeln;
}
Bye,
bearophile
Re: Memory safety depends entirely on GC ?
Andrei Alexandrescu: It definitely is a good thing. The question is balancing its goodness against the costs of allowing it. It's not impossible you may get asked to change your code to use a struct instead of a fixed-sized array. I don't like the look of the annotations of DIP25. I'd like DIP25 removed from D language and replaced by a more principled solution. Sometimes a heavier solution can be simpler to understand (and it can be actually safe). Bye, bearophile
Re: Memory safety depends entirely on GC ?
Andrei Alexandrescu: using stack-allocated arrays in safe code is a rather niche use). I use stack-allocated arrays in supposedly safe code. And having a future D compiler that makes that kind of code actually safe is a good thing. Bye, bearophile
Re: A Refcounted Array Type
Walter Bright: 5. bounds checking When you go past bounds of a built-in array you get an error located in the user code, while if you put a pre-condition in your Array struct to detect the same errors, you get a run-time error message located in that pre-condition instead. I'd like some way to solve this small problem of giving more correctly located error messages. In Contract programming lingo it's a problem of "blame management" (I'd also like a way to detect some compile-time out-of-bound errors for user-defined collections, but you said this is not worth the effort). Bye, bearophile
Re: Let's Play Code Golf
Steve Sobel:
It can get down to 155 using ranges, but those imports really
are killer.
You usually don't want to design a language for code golfing (but
several exist, like http://esolangs.org/wiki/GolfScript ).
void main(){import
std.algorithm,std.conv,std.range,std.stdio;foreach(n;stdin.byLine.drop(1))writefln("%.15f",iota(n.to!int).map!"(-1.0)^^a/(2*a+1)".sum);}
You can remove one char:
iota(n.to!int).
n.to!int.iota.
Bye,
bearophile
Re: DDMD just went green on all platforms for the first time
Benjamin Thaut: Are there any performance comparisons? E.g. how long das DDMD take to compile phobos vs regular DMD? Yes, there are several performance comparisons I'm curious about, like binary size, compilation speed, compilation speed of the compiler, max memory to compile Phobos without unittests, and few more basic data points. Bye, bearophile
Re: contiguous ranges
Andrei Alexandrescu: for an array r, is r.retro contiguous or not? Is the most useful contiguous range forward? So can you name it ForwardContiguousRange? Bye, bearophile
Re: Consistency
John Colvin: I'm quite a fan of python's // operator for integer division, especially when combined with python 3's choice to make / always mean floating point division (i.e. 3/2 == float(3)/2, 3//2 == 1). It recognises that integer division is a weird thing and separates it from the much less weird floating point division. The C/D division operator semantics is a bug-prone design mistake, and this design was fixed in Python3 despite this has broken lot of Python2 code. It's a pitfall that a modern language must avoid (I don't know how Rust handles divisions, I hope they have removed this problem). Bye, bearophile
Re: contiguous ranges
Vlad Levenfeld: a ContiguousRange would be any RandomAccessRange which has a member called ptr which supports a dereferencing operator * that yields an ElementType!R. This notion is useful for functions which might otherwise perform an element-by-element transfer to an OutputRange via put, instead perform an optimized batch transfer directly to a ContiguousRange via ptr. Increasing the number of basic ranges will lead to a little more complexity, but this seems a nice idea. Bye, bearophile
Re: Consistency
Daniel Murphy: No, they were still O(n) worst case, for a single bucket with a degenerate binary tree. I see. I was unable to hit this degenerate case in my testing code, but I guess that was possible. Thank you. Bye, bearophile
Re: Consistency
Meta: Oh, whoops. I mixed up average-case complexity with worst-case. Although, isn't lookup O(n) in the worst case for hash tables? D associative arrays used to be O(1) amortized and O(n ln n) in worst case. Now they are O(1) amortized and O(n) worst case. And for an adversary it's not too much hard to find and hit that O(n) case. Bye, bearophile
Re: Consistency
Xinok: In that respect, it only makes sense for dictionaries Values as in Python are much more useful for arrays :-) Meta: D is better off than Python in this case, I've never subscribed with point of view :-) Bye, bearophile
Re: Consistency
John Colvin: tup1.expand.only.countUntil(2).writeln; Admittedly, it's a little longer than expected :) A little shorter: tup1[].only.countUntil(2).writeln; Bye, bearophile
Re: A safer interface for core.stdc
H. S. Teoh: Come to think of it, is there any point in making malloc @safe/@trusted at all? I am not asking for a @trusted function. I'd like a @system template wrapper for malloc/calloc/free that is safer than the C functions (safer because it's type-aware). Bye, bearophile
Re: A safer interface for core.stdc
Andrei Alexandrescu: Such wrappers would allow safe code to use more C stdlib primitives. I'd also like a safer templated wrapper for calloc() and malloc() and similar. Bye, bearophile
Re: Another idiom I wish were gone from phobos/druntime
Ola Fosheim Grøstad: Ada with SPARK 2014 makes D look like it is stuck in the 80s: 4.2. Subprogram Contracts 4.2.1. Preconditions 4.2.2. Postconditions 4.2.3. Contract Cases 4.2.4. Data Dependencies 4.2.5. Flow Dependencies 4.2.6. State Abstraction and Contracts 4.2.6.1. State Abstraction and Dependencies 4.2.6.2. State Abstraction and Functional Contracts 4.3. Package Contracts 4.3.1. State Abstraction 4.3.2. Package Initialization 4.3.3. Package Initial Condition 4.3.4. Interfaces to the Physical World 4.3.4.1. Volatile Variables 4.3.4.2. Flavors of Volatile Variables 4.3.4.3. External State Abstraction 4.4. Type Contracts 4.4.1. Scalar Ranges 4.4.2. Static Predicates 4.4.3. Record Discriminants 4.4.4. Default Initial Condition 4.5. Specification Features 4.5.1. Attribute Old 4.5.1.1. In a Postcondition 4.5.1.2. In Contract Cases 4.5.1.3. In a Potentially Unevaluated Expression 4.5.2. Attribute Result 4.5.3. Attribute Loop_Entry 4.5.4. Attribute Update 4.5.5. Conditional Expressions 4.5.6. Quantified Expressions 4.5.7. Expression Functions 4.5.8. Ghost Code 4.5.8.1. Ghost Functions 4.5.8.2. Ghost Variables Case 1: Keeping Intermediate Values Case 2: Keeping Memory of Previous State Case 3: Logging Previous Events 4.5.8.3. Ghost Types 4.5.8.4. Ghost Procedures 4.5.8.5. Ghost Packages 4.5.8.6. Imported Ghost Subprograms 4.6. Assertion Pragmas 4.6.1. Pragma Assert 4.6.2. Loop Invariants 4.6.3. Loop Variants 4.6.4. Pragma Assume 4.6.5. Pragma Assert_And_Cut That seems a bit too much for the average human to handle :-) Sometimes features help, but that list seems excessive for a language that is not meant for high integrity systems as D. Bye, bearophile
Some notes on Rust
In the best language blog: http://lambda-the-ultimate.org/node/5113 The discussion is long. They discuss if a good GC can be written in the language itself, about actual security, what a GC can and can't do, and more. Bye, bearophile
Re: Another idiom I wish were gone from phobos/druntime
Zach the Mystic: I have an idea. Treat all assert statements which come before the first non-assert statement as part of the 'in' contract. I'm not saying the compiler has to generate a whole 'in' function, but these asserts can be internally tagged to behave *as if* in an 'in' contract. That solves the tooling problem and the too-much-code problem, no? Bad idea. We had DbC, let's start using it. Bye, bearophile
Re: Another idiom I wish were gone from phobos/druntime
Andrei Alexandrescu:
auto opSlice(size_t low, size_t high)
in
{
assert(low <= high);
}
body
{
import std.range : take;
return this[low .. $].take(high - low);
}
which of course trivially boils down to:
auto opSlice(size_t low, size_t high)
{
assert(low <= high);
import std.range : take;
return this[low .. $].take(high - low);
}
What advantage could possibly be in transforming a 5-liner into
a 9-liner?
Contracts can be read by tools, and they are part of the function
signature. Contracts should be encouraged and increased, not
discouraged.
Bye,
bearophile
Re: FYI - DIP25 is approved for 2.067
Andrei Alexandrescu: http://wiki.dlang.org/DIP25 I'd like a more comprehensive and flexible solution to the problem of static memory ownership. Bye, bearophile
Re: Arrays, garbage collection
deadalnix:
- added optimization to promote them on heap. Thing like
int[2] = [1, 2] can trivially avoid GC allocation.
See my usage examples (think of the examples as not having the
"s" suffix):
void main() {
// Some imports here.
foo([[1, 2]s, [3, 4]]s);
auto t1 = tuple([1, 2]s, "red");
auto aa1 = ["key": [1, 2]s];
auto pairs = 10.iota.map!(i => [i, i + 10]s);
}
A smart system can promote only the first one to value array. The
compiler has to leave the other cases to the judgement of the
programmer.
- added some support for ownership/lifetime. This will allow
the compiler to promote even more on heap.
This is what I too have said in my original post. For those
features to work well you need first a good static management of
memory ownership.
If don't expect the new syntax to be that useful if these point
are addressed. If I'm turn out to be wrong, we can reconsider
at that point.
I can show code similar to the examples above where the []s
syntax is useful.
And using a function as Andrei suggests is not a good idea:
foo(staticArray(staticArray(1, 2), staticArray(3, 4)));
I don't think lot of people is going to write code like that.
And if you are about to suggest this:
alias S = staticArray;
Well, do you like to see aliases in your code?
Bye,
bearophile
Re: Arrays, garbage collection
Andrei Alexandrescu: No, we need to define a function for that - please file an enhancement request, thanks. -- Andrei No, the enhancement is in Bugzilla since lot of time. But it's for a built-in syntax. A function name is too much long, and when the inlining is switched off it makes the code bad. Thanks. Bye, bearophile
Re: Arrays, garbage collection
Daniel Kozák: No, it makes more bugs possible // this is compile error so its ok int[MUST_HAVE_FIVE_ITEMS] a=[1,2,3,5]; // Error: mismatched array lengths, 5 and 4 Have you tried to compile my code? It doesn't give an error. Bye, bearophile
Arrays, garbage collection
The D type inference for array literals is now more flexible:
void main() {
auto[$][$] m1 = [[1, 2], [3, 4], [5, 6]];
pragma(msg, typeof(m1)); // int[2][3]
const auto[string] aa1 = ["red": 1, "blue": 2];
pragma(msg, typeof(aa1)); // const(int)[string]
}
It helps avoid bugs like:
int[5] a = [1,2,4,5];
void main() {}
And it makes the usage of value arrays (fixed size arrays) more
handy. We need to minimize the work that the garbage collector
has to do. Value arrays help in this. So making value arrays more
handy and natural to use is good (regardless how the current
Phobos hates them).
- - - - - - - - -
What's missing is a handy and compiler-efficient syntax to create
value array literals. Some persons have proposed the "[]s" syntax:
void main() {
// Some imports here.
foo([[1, 2]s, [3, 4]]s);
auto t1 = tuple([1, 2]s, "red");
auto aa1 = ["key": [1, 2]s];
auto pairs = 10.iota.map!(i => [i, i + 10]s);
}
To do those same things without the []s syntax you have to write
longer code.
- - - - - - - - -
Another missing handy feature regards dynamic/associative arrays
(this syntax is currently accepted):
void main() {
scope int[] a = [1, 2];
scope int[int] aa = [1: 2];
}
A good management of memory ownership is needed to make "scope
dynamic/associative arrays" fully safe. They should be more
efficient for the GC because they can be deallocated safely when
the scope ends, without no need for the GC to track their usage
(if they contain references to objects that contain other
references, then the GC has to track and manage those other
references).
- - - - - - - - -
Sometimes I have suggested that it's useful to have in Phobos a
kind of variable-length value arrays that are handled in a
special way by the compiler when they are allocated in a stack
frame, usable in @nogc functions (so it's a hybrid Phobos/D
feature). This should give the advantages of C99 Variable Length
Arrays without most of their disadvantages and complexities (the
main disadvantage that's left is the risk of stack overflow.
Currently on Windows D doesn't give a nice error message when the
stack overflows, as it used to do).
- - - - - - - - -
With those features, with a good static management of memory
ownership, D can become safer and reduce the work for the GC. I
think only a limited percentage of arrays need to be fully
handled by the GC.
Bye,
bearophile
From C#7 and Haskell
Design Notes for C#7: https://github.com/dotnet/roslyn/issues/98 Perhaps they will enhance C# switch (plus an optional special method) to support a form of pattern matching. I'd like something related in D, someday. - - - - - - - "Haskell in the large" (PDF): http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf It's perhaps the first time I see Haskell used for a large program and system. << New things: - Data mining: In-language relational algebra data structures and API. - Memoization: In-language data flow graph library with memoization support. Native relational algebra data type. - An awful lot of data mining and analysis is best done with relational algebra. - Not just in the database. Bye, bearophile
Re: accept @pure @nothrow @return attributes
Ola Fosheim Grøstad: [0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10)) The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-) Bye, bearophile
Re: accept @pure @nothrow @return attributes
Dicebot: Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) Bye, bearophile
