__traits(allMembers, mixin(__MODULE__)) also yields a module name
like object, but then how can you find out that object is a
module?
This doesn't work:
void main() {
pragma(msg, is(int == int));
pragma(msg, is(object == module));
}
Bye,
bearophile
On Monday, 26 January 2015 at 14:02:54 UTC, ref2401 wrote:
What's the difference between static class and static struct?
What should i use?
Non-static structs/classes have an extra pointer. Static ones
don't have it, so their differences are the usual ones: a class
is used by reference and
Walter Bright:
Previously, it's all been advocacy and break my code
Breaking the code should be justified by a worth gain. This patch
is of negative value.
Bye,
bearophile
Russel Winder:
but is it's name group by as understood by the rest of the
world?
Nope...
Bye,
bearophile
Jonathan M Davis:
Personally, I'd much prefer that we not make this change. It's
just shuffling things around in an attempt to make them more
consistent while actually making them _less_ consistent.
So far I agree with Jonathan.
Bye,
bearophile
Vlad Levenfeld:
What's this about !`[]` and std.range.uniform?? It's not in the
documentation.
It's an enhancement I have proposed.
Bye,
bearophile
Dominikus Dittes Scherkl:
Because this is useful in more situations,
Right, but it's still a cast. And in D you want to minimize the
number of usages of casts. The proposed syntax iota![] is
cast-safe.
Bye,
bearophile
Laeeth Isharc:
I think concatenation and append are used as synonyms (the same
meaning is meant). a~=b or a=a~b
a=a~b always allocates a new array, while a~=b sometimes
re-allocates in place.
Bye,
bearophile
Dominikus Dittes Scherkl:
Has anyone any idea how to work around this?
In Bugzilla I have proposed to solve this problem with this
syntax taken from std.range.uniform:
iota
Bye,
bearophile
AndyC:
On a side note, as if I find old bug reports that can just be
closed whats the best way for me to report it?
You can add a comment to the issue.
Bye,
bearophile
Ary Borenszweig:
In most languages group by yields a tuple of {group key, group
values}.
I'm saying this since some years... (and those languages probably
don't use sorting to perform the aggregation).
Bye,
bearophile
H. S. Teoh:
What you describe could be an interesting candidate to add,
though. It
could iterate over distinct values of the predicate, and
traverse the
forward range (input ranges obviously can't work unless you
allocate,
which makes it no longer lazy) each time. This, however, has
O(n*k)
aldanor:
auto lines = stdin.byLine.map!(line = line.length);
writefln(Average line length: %.4f., 1.0 * lines.sum /
lines.array.length);
Ofc this is not the greatest piece of code ever and it's not
lazy,
lines.walklength seems better than lines.array.length, but you
can also use
Yes, it's worth adding to Phobos.
The issue:
https://issues.dlang.org/show_bug.cgi?id=14034
Bye,
bearophile
zeljkog:
Loosely-related, compiling
...
auto ret = arr.filter!(myFilter());
...
I got:
Error: closures are not yet supported in CTFE
Using struct with opCall directly also does not pass.
Did I miss something?
Is it near?
Please show a minimal nonworking example in the D.learn newsgroup.
Fool:
Jonathan Blow published another video [1] presenting the
progress of his language. He is treating two main topics:
- a keyword preliminary called 'using' which seems to be quite
close to 'alias this';
- an annotation SOA for pointers and arrays which allow high
level treatment of
drug:
Also can I avoid dummy non-default ctor for Bar?
One solution:
struct Foo {
int foo;
@disable this();
this(int foo_) pure nothrow @safe @nogc {
this.foo = foo_;
}
}
struct Bar {
enum arraySize = 3;
Foo[arraySize] foo = Foo(1);
}
void main() @safe {
tcak:
Well, that's just disguising what we can't do.
When the a..b syntax was added to foreach() someone criticized
that syntax saing it's a one trick pony, and indeed I don't
know why Walter didn't make it a little more first-class.
But note that in D the a..b ranges are always open on
Jonathan M Davis:
auto r = chain(uiota('a', 'z'), uiota('A', 'Z'), uiota('0',
'9'));
Those ranges are probably open on the right.
In Bugzilla I have asked for the syntax iota to
change how the extrema are handled, modelled on
std.random.uniform syntax.
---
Kagamin:
Jonathan M Davis:
but that's easy fixed with some +1's.
But the +1 changes the char to an int.
Bye,
bearophile
Andrei Alexandrescu:
There's this classic patter on Unix: |sort|uniq, i.e. sort some
data and only display the unique elements.
In Bugzilla I've asked for a hashGroup, it returns a built-in
associative array.
Bye,
bearophile
Steven Schveighoffer:
scoped int[] a=new int[whatever_big_size];
...
I would not use this, I think it's scheduled for deprecation,
or at least the meaning is scheduled to change.
As D introduces some limited static management of memory
ownership, the semantics of scoped arrays could be
Andrei Alexandrescu:
What would be a better integrated version - one that does
sorting and uniq in one shot? I suspect the combination could
be quite a bit better than doing the two in sequence.
What I need most is a groping by hashing, since years. A unique
sort can be handy, but it's less
Paul O'Neil:
Is that different than groupBy?
It works with hashing, and doesn't require a sorting, so it's
different. On the other hand it's just few lines of code long,
and it's quite easy to write...
Bye,
bearophile
ddos:
iota(0,100).map!(v = uniform(0.0,1.0)).writeln;
You can also write:
100.iota.map!(_ = uniform01).writeln;
Bye,
bearophile
It works for me:
Sorry, you are right, it loops:
void main() {
import std.stdio, std.bigint;
immutable BigInt one = 1;
immutable BigInt two = 2;
uint n = 0;
foreach (immutable i; two .. n + one)
i.writeln;
}
Bye,
bearophile
Russel Winder:
However for BigInt:
for(i; two..n + one)
the loop starts at 0 and just keeps on going. This is clearly
not good.
It works for me:
void main() {
import std.stdio, std.bigint;
immutable BigInt one = 1;
immutable BigInt two = 2;
uint n = 100;
tcak:
So, at the end of the day (I left working on my Matcher class
in the morning waiting an answer for this question), there is
nothing to convert ['a'..'d', '0'..'3'] to ['a', 'b', 'c', 'd',
'0', '1', '2', '3'] at compile time automatically.
Right. The 'a'..'d' is not first class, and
ddos:
auto numbers = iota(0,1).map!(_ = uniform(0.0,1.0)).array;
Better:
const numbers = 10_000.iota.map!(_ = uniform01).array;
auto nmin = numbers.reduce!((a,b) = min(a,b));
Better:
immutable nMin = numbers.reduce!min;
You can also combine both (untested):
immutable nMinMax =
The sizeof values aren't relevant for D array casts. What
matters are the array contents.
See:
void main() {
int[5] m = cast(int[5])[1, 2, 3, 4, 5];
assert(m == [1, 2, 3, 4, 5]);
pragma(msg, m.sizeof); // 20u
pragma(msg, [1, 2, 3, 4, 5].sizeof); // 8u
}
Bye,
bearophile
anon:
I got it working with.
auto info = new Info[][](hl, vl);
and changing the logic so as not check for the NULL.
That's probably a better and simpler translation. I have tried to
translate your original code too much literally.
Bye,
bearophile
anon:
I have the following C code, how can I do the same in D.
Info **info;
info = new Info*[hl + 2];
int r;
for(r = 0; r hl; r++)
{
info[r] = new Info[vl + 2];
}
info[r] = NULL;
I suggest you to ignore ketmar, he's not helping :-)
Is your code initializing info[r+1]?
This is
deadalnix:
That is reasonable to expect a compiler to remove such a check
with optimization enabled already. I'm not sure about DMD, but
I'd be willing to bet that LDC and GDC already do it.
I think this thread is about an enhancement request for a
guaranteed front-end optimization.
Bye,
anon:
It looks like what I need.
But what's the purpose of the last two empty arrays?
Bye,
bearophile
Baz:
int[3] m = cast(int[3])[1, 2, 3];
writeln(m.sizeof);
writeln([1, 2, 3].sizeof);
The sizeof values aren't relevant for D array casts. What matters
are the array contents.
Bye,
bearophile
Currently this is accepted:
int[2] m = cast(int[2])[1, 2];
But Kenji suggests that the cast from int[] to int[2][1] should
not be accepted. Do you know why?
Reference:
https://issues.dlang.org/show_bug.cgi?id=7514
Bye and thank you,
bearophile
Rikki Cattermole:
I'm guessing something along these lines:
A Phobos patch:
https://github.com/D-Programming-Language/phobos/pull/2881
Bye,
bearophile
ketmar:
Jonathan explains it very well. i can add the only thing: don't
use `const` until you forced to. ;-)
In D use immutable (or const) everywhere you can. Possibly mark
as immutable everything doesn't need to mutate.
sure, you can cast `const` away in your code, but using `cast`
is a
Vladimir Panteleev:
All expandable sections should show up as expanded when no JS is
available.
But currently they aren't doing that, right?
Bye,
bearophile
Vladimir Panteleev:
If it doesn't work for you, how can I reproduce the problem?
Today browsers are terribly complex, there's little hope to
reproduce an environment. So never mind, ignore my precedent
comment...
Bye,
bearophile
Andrei Alexandrescu:
I think we're in a better place than before.
If the browser detects no JavaScript it can present a simpler
alternative but usable menu.
Bye,
bearophile
Kiith-Sa:
http://developers.slashdot.org/story/15/01/20/2026221/is-d-an-underrated-programming-language?utm_source=rss1.0mainlinkanonutm_medium=feed
One interesting comment:
http://developers.slashdot.org/comments.pl?sid=6771453cid=48860193
That's the funny thing about languages like D or Go
Nordlöw:
wouldn't it be better to detect the mismatches between enum
bit-sizes and bitfield lengths at compile-time instead of at
run-time?
File an enhancement and/or submit a Phobos patch.
Bye,
bearophile
Per Nordlöw:
I'm looking for a function that figures out the number of bits
that are needed to represent a zero-based integer:
//
http://stackoverflow.com/questions/3272424/compute-fast-log-base-2-ceiling
uint ceilLog2(ulong x) pure nothrow @safe @nogc
in {
assert(x 0);
} body {
NA:
http://interviews.slashdot.org/story/15/01/19/159242/interviews-alexander-stepanov-and-daniel-e-rose-answer-your-questions
I am glad to see that the field of programming languages is far
from done :-)
AlexAfter STL was accepted into the standard in 1994, I started
thinking about
Tobias Pankrath:
What's up with that 'filename syntax?
I think such little details are not important for this Phobos
thread.
Bye,
bearophile
An interesting library for Scala language (found through Reddit):
https://github.com/lihaoyi/Ammonite#ammonite-010
I think this library is interesting for D not for its command
line usage nor for the details of its syntax (that I think is too
much succinct), but as an example of things you
Walter Bright:
Sure, but you'll need a rationale that is better than why not
:-)
Often in a language it's a good idea to have only one way to do
something. To have two places to put those attributes generates
the question: where do you want to put them? And it's a question
that wastes
Walter Bright:
On 1/16/2015 3:10 PM, zeljkog wrote:
Why is it restricted to @safe?
Being a systems programming language, an escape from it may be
necessary.
But this DIP to have a meaning should go with a @safe by
default, I think.
Bye,
bearophile
Andrei Alexandrescu:
I wonder how to feature Rosetta Code more prominently on
dlang.org.
I don't know. One option is to create a kind of FAQ page in the
D wiki, that associates problems and questions with links to
specific entries in the Rosettacode site.
Bye,
bearophile
Mengu:
i've noticed there are some code that are not working such as
the anonymous recursion example. [0] the first example there
doesn't work
I have fixed the bug. If you find other problems please list them
in a single thread in D.learn (but keep in mind that Rosettacode
D code is meant
Mengu:
i've noticed there are some code that are not working such as
the anonymous recursion example. [0] the first example there
doesn't work but the second one works with DMD64 D Compiler
v2.066.
The code used to work... I fix all the time the code that used to
work...
let's get
According to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
C++14 is able to compile code like this:
auto correct(int i) {
if (i == 1)
return i;
else
return correct(i - 1) + i;
}
But not like this:
auto correct(int i) {
if (i !=
Xinok:
I played with it a bit and it seems to deduce a common type
from all the return statements,
Right, this works according to the D specs (but this is different
from the feature I have suggested in the original post).
Bye,
bearophile
ketmar:
the spec says that return type for `auto` function is taken
from the first `return` operator parser met. so for the
second `return` the return type is already known.
Do you mean the C++14 spec or the D spec?
The D specs I see are (from: http://dlang.org/function.html ):
Auto
Xinok:
auto one(int i)
{
if(i 0)
return cast(int)i;
else
return cast(float)i;
}
With recent D2 compilers I suggest you to get used to write code
like that like this:
auto one(int i)
{
if(i 0)
return int(i);
qqiang:
I've googled and found no straightforward solution to this
issue. The how can I modify my code to eliminate this error?
Your code gives me a different error (Error: PowerHeap!int is
used as a type).
What if you replace the SList with a dynamic array?
Bye,
bearophile
Adam D. Ruppe:
I've started writing a weekly D newsletter. Here's the first
issue, any feedback welcome!
http://arsdnet.net/this-week-in-d/jan-12.html
Seems good.
Major Changes = They are weekly, so perhaps Changes is
enough.
If you can, add two or three little images to the page, like
Nordlöw:
Has there been any discussions on
making map require pure functions now that we have each?
Perhaps I'd like Phobos map and filter to be annotated with
pure and to have a template constraint that requires their
mapping/filtering functions to be strongly pure.
Bye,
bearophile
ketmar:
that will effectively rule out any usage of some global vars or
other
external state, turning it into either unnecessary mess, or
unusable
theoretical crap.
Unusable theoretical crap is better than the current trap :-)
We hare pure in D, but still we have not grown up to actually
Ola Fosheim Grøstad:
I've tried to like STL for 17 years, and whenever speed and
clear programming matters it is basically a good idea to throw
it out.
Take a look at the ideas of C++ seasoning
(http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning
), where they suggest to do kind
ketmar:
in no way. this just turns Phobos into the same unusable crap,
removing the whole sense of having good standard library.
If your language has purity, and it doesn't use it where it
matters, you have removed its sense of having purity. So if you
are right then purity in D is useless
anonymous:
a |= 1 16;
In D there's also the 2 ^^ x syntax available.
Bye,
bearophile
Walter Bright:
I do understand that the packed error code technique can be
made to work, but the inconvenience seems to be high.
Apparently if the language syntax is designed for that style of
functional programming, the inconvenience seems to be very low.
Bye,
bearophile
Walter Bright:
Yes, it still appears to be just a wrapper around returning two
values, and that has to be done for everything.
There's lot of functional theory behind such ideas.
There's another downside to returning two values - extra code
is generated, and it consumes another register.
Ola Fosheim Grøstad:
(Most of std::C++ is optional, templated and inefficient...
There is no consistent culture. Though they got some thing
right with unique_ptr and new language features recently.)
I don't agree. The basic ideas of STL by Alexander Stepanov are
very good. Phobos contains
tcak:
One way I achieved it, though I cannot put namespace on it.
file: project.d
==
module project;
class project{}
D modules can contain lot of stuff, like variables, constants,
enums, types, structs, etc. And you usually put more than one
class in each D module. Also D
ponce:
Rust is supposed to replace C++, and it happens working in C++
since years, I can't help but notice we actually have very few
memory safety problems,
Are you always able to detect them? I think languages (and
programmers) that don't have a strict attitude toward memory
safety will
Nordlöw:
Is doCopy really needed as an argument here?
Couldn't this be inferred from the mutability of T instead?
doCopy is useful, if it's true all the permutation arrays are
distinct and dup-ped, otherwise they are all different. It's true
by default, so casual users of that generator
Nordlöw:
Couldn't we do a first pass and check that if elements of T are
distinct and if so set doCopy to false otherwise true?
The algorithm you have seen in Rosettacode doesn't care if and
what items of the input sequence are duplicated, it handles them
as they are all distinct. And them
Adam D. Ruppe:
Don't use git master :P
Is the issue in Bugzilla?
Bye,
bearophile
Laeeth Isharc:
I understand from previous discussion there is some difficulty
over immutability. I did not quite figure out what the
solution was in this case:
import std.array;
import std.string;
import std.stdio;
void main(string[] args)
{
string[] test=[1,two,three!];
Laeeth Isharc:
In D there is a feature that allows a function to accept both
an array of items and items,
yes - it is funny there is not an overloading that accepts
arrays
I meant this D feature:
void foo(T)(T[] items...) {
import std.stdio;
items.writeln;
}
void main() {
Vlad Levenfeld:
auto tex1 = ℕ[0..100].by (ℕ[0..100]).map!((i,j) = (i+j)%2?
red: yellow).Texture;
auto tex2 = ℕ[0..50].by (ℕ[0..50]).map!((i,j) = (i+j)%2?
blue: green).grid (100,100).Texture;
tex1[50..75, 25..75] = tex2[0..25, 0..50];
The library seems nice, but I don't like
Robert burner Schadek:
IMO, If you slice a double array it is always aligned. Because
doubles are 8 bytes long aka 64bit which would align them to
every fourth 16bit boundary.
If you have a 16-byte aligned array of doubles and you slice the
first double away, what's the alignment of the
Luc Bourhis:
With auto a = new double[1000], is there any guarantee that
a.ptr is aligned on a 16-byte boundary?
Arrays are aligned on a 16-byte. But if you slice them, this
alignment can be broken.
In past I suggested to put the alignment of an array in the D
type system, as an optional
ponce:
I'm not familiar with the terse, range-heavy, UFCS style that
has emerged from Phobos
In Rosettacode I have inserted tons of examples of that coding
style.
An example, given a tuple of arbitrary length, with items all of
the same type, how do you compute the total of its items?
Nick:
The two nodes have the same address, is this right?
What you are printing is the address of the reference in the
stack frame of add(). If you want to print the reference you can
use this:
import std.stdio;
class Test(T) {
static class Node {
T v;
}
void add(T
FrankLike:
But now I want to know in a string (like hello.exe or
hello.a,or hello.dll or hello.lib ) whether contains any
of them: [exe,dll,a,lib].
Seems this:
http://rosettacode.org/wiki/File_extension_is_in_extensions_list#D
Bye,
bearophile
Suliman:
I need to construct complex SQL request, like:
string sql = (INSERT INTO test.geomagnetic (`date`,
`a_fredericksburg`, `fredericksburg`, `a_college`, `college`,
`a_planetary`, `planetary`) VALUES ('%s', '%s', '%s', '%s',
'%s', '%s', '%s');, date[i], a_fredericksburg[i],
Nordlöw:
How do I make
foreach (E; EnumMembers!T)
- iterate dynamically instead of statically (no loop unrolling)
and
- skip enumerator aliases?
Try:
foreach (immutable e; [EnumMembers!T].sort().uniq)
Bye,
bearophile
Dominikus Dittes Scherkl:
Yeah. I wish it would be possilbe to do something like:
alias @smooth = @save pure nothrow @nogc;
and then use this instead.
You most probably want something more principled instead, as the
algebra of effects of Koka language
deadalnix:
Tuple unpacking is necessary for things like bypair. Why not
unpack consistently ?
I'm all for unpacking consistently, but to reach consistency you
first have to break something, the iteration on arrays or the
iteration on ranges of tuples. The first is documented and it's
Suliman:
void foo()
{
writeln(test);
writeln(mystring);
}
foo();
}
I guess you have to remove that line.
Bye,
bearophile
I strongly suggest to burn with fire, I mean, warn and then
deprecate the special case of automatic tuple unpacking in
foreach loops in dmd 2.067:
void main() {
import std.typecons, std.range;
auto data1 = [tuple(red, 10), tuple(blue, 20)];
foreach (x, y; data1) {
In Phobos we have std.array.assocArray that allows to build a
built-in associative array from a range of key-value Phobos
Tuples (it will become mostly legacy when we will have a good
associative array in Phobos and built-in tuples in D, that is the
opposite of the data structures we have
Daniel Murphy:
Every C++ programmer has hit this bug at some point:
struct S
{
int a;
S(int a)
{
a = a;
}
};
I have a bug report for something like that [TM]:
https://issues.dlang.org/show_bug.cgi?id=3878
Bye,
bearophile
Ary Borenszweig:
Are there proofs of percentage of bugs caused by incorrectly
mutating variables that were supposed to be immutable?
I don't know, probably not, but the progress in language design
is still in its pre-quantitative phase (note: I think Rust
variables are constant by default,
Manu:
I've run into this many times in the past too... never really
thought
on it whether it's a problem that could actually be solved.
Sometimes one way to realize you have a problem worth trying to
solve is to push your mind sideways to a more naive state (in my
original post in this
Ary Borenszweig:
But now to make the code fast you have to annotate things with
pure nothrow @safe to make sure the compiler generates fast
code.
Do you have any proof of this?
Nim has 363 issues accoring to
https://github.com/Araq/Nim/issues . D has 2444 according to
So are Nim
Walter Bright:
Nim:
for neighbour in nodes[nodeId].neighbours:
D:
foreach(immutable route neighbour; nodes[nodeID].neighbours){
Correctly written D:
foreach (neighbour; nodes[nodeID].neighbours){
I don't agree, the good D way is:
foreach (immutable neighbour;
Vlad Levenfeld:
Can the compiler automatically make variables immutable if it
can prove that they are never changed in some code?
This is very different from what I am saying. The C compilers
don't go to add a const annotation to your source code (but
perhaps the Rust compiler warns about
Ary Borenszweig:
D programmers should apply const/immutable to every variable
that
doesn't need to mutate.
Why?
Since some years Computer Science has found that the right
default for variables is to have them immutable, and to have them
mutable on request.
Immutable variables make the
It's a design mistake, but there's a fold function
replacement for reduce that has the right order of arguments. I
don't know why fold isn't in Phobos yet.
https://github.com/D-Programming-Language/phobos/pull/1955
https://issues.dlang.org/show_bug.cgi?id=10670
Bye,
bearophile
weaselcat:
Why does reduce! take the seed as its first parameter btw? It
sort of messes up function chaining.
It's a design mistake, but there's a fold function replacement
for reduce that has the right order of arguments. I don't know
why fold isn't in Phobos yet.
Bye,
bearophile
H. S. Teoh:
When are we going to fix this?
Soon.
Bye,
bearophile
This doesn't compile because T is const(int) so you can't modify
the arguments a and b, despite they are values:
void foo(T)(T a, T b) {
a = b;
b = a;
}
void main() {
const int x, y;
foo(x, y);
}
To make that code work I'd like to write something like this:
void
Tobias Pankrath:
Like Unqual!T?
It doesn't seem to work:
void foo(T)(Unqual!T a, Unqual!T b) {
a = b;
b = a;
}
void main() {
const int x, y;
foo(x, y);
}
Bye,
bearophile
Meta:
Wouldn't it be better to do this at the call site anyway? Just
use a simple function.
Unqual!T unconst(T)(T val)
if (isScalarType!T)
{
return val;
}
void foo(T)(T a, T b)
{
a = b;
b = a;
}
void main()
{
const int x, y;
foo(x.unconst, y.unconst);
}
That's an
void foo(T)(Unqual!T a, Unqual!T b) {
a = b;
b = a;
}
void main() {
const int x, y;
foo(x, y);
}
Missing line:
import std.traits: Unqual;
Bye,
bearophile
201 - 300 of 1477 matches
Mail list logo
