On 26/12/2014 18:38, bearophile wrote:
In C# i would use something like:
int ThisNumber;
ThisNumber = Console.ReadLine();
in D it looks worse with its old way of doing it:
int thisNumber
readf(%s, thisNumber);
Do you want to use a %d?
A more common way to do it in D is something like:
On 24/12/2014 06:18, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
lazy was implemented in Algol and then shunned in just about all
languages that followed.
FWIW Apple's recent Swift has @autoclosure, which is the same as lazy.
It's needed to implement assert in Swift.
On 18/12/2014 08:58, ketmar via Digitalmars-d wrote:
too much work for toy hobbyst project.
In case you want free Git hosting other than github, check:
https://git.wiki.kernel.org/index.php/GitHosting
Some sites have an open framework.
On 15/12/2014 19:39, H. S. Teoh via Digitalmars-d wrote:
If you put your git repo online somewhere, I wouldn't mind pulling from
it and pushing to Phobos as PRs. It's much more convenient than
downloading patches off bugzilla. (Git was designed to be used this way
in the first place!)
+1, it
On 11/12/2014 09:07, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
If I as a programmer know that something is safe, then the compiler
should accept it, and the language should allow me express it.
It will, use @system. Maybe this proposal will be supplemented later,
but
On 09/12/2014 16:25, Steven Schveighoffer wrote:
Will ref just automatically bind to any scoped reference?
A ref parameter essentially is a scope ref parameter, but it can also be
returned:
http://forum.dlang.org/post/m64v3g$2bga$1...@digitalmars.com
On 08/12/2014 15:53, Steven Schveighoffer wrote:
scope ref int foo(ref int x);
will do it.
So:
int x;
foo(x) += 1;
will compile?
Yes, because foo's argument is not scope, it can be returned.
On 09/12/2014 16:25, Steven Schveighoffer wrote:
But I thought if you take a reference from the stack, it's inferred as
scope? I feel like there's a missing link somewhere if the scope is
missing from the parameter.
I think (with this DIP) values on the stack can safely be passed as a
ref
On 05/12/2014 23:58, Walter Bright wrote:
2) `scope ref` return values cannot be stored.
scope ref int foo();
void bar(scope ref int a);
foo().bar();// allowed
scope tmp = foo(); // not allowed
tmp.bar();
Right
From the DIP:
The lifetime of a scope return
On 04/12/2014 12:55, bearophile wrote:
Regarding array literals, some people proposed a syntax for fixed-size
arrays to avoid heap-allocations (the s after the array literal):
void foo(int[2]) {}
void bar(scope int[]) {}
void main() @nogc {
foo([1, 2]s);
bar([1, 2]s);
}
I think even
On 04/12/2014 21:23, H. S. Teoh via Digitalmars-d wrote:
@property scope ref T borrow() { return t; }
alias borrow this;
While this DIP enabling the above to be memory-safe is awesome, a later
tweak to AliasThis grammar to allow storage classes could make 'borrow'
redundant.
On 03/12/2014 23:02, Martin Nowak wrote:
On 11/27/2014 10:30 AM, Gary Willoughby wrote:
There seems to be an effort to resurrect ctags[1] so i've taken the D
language support from this patch and applied it to the newly resurrected
ctags.
[1]: https://github.com/fishman/ctags
How about making
On 27/11/2014 09:30, Gary Willoughby wrote:
There seems to be an effort to resurrect ctags[1] so i've taken the D
language support from this patch and applied it to the newly resurrected
ctags.
[1]: https://github.com/fishman/ctags
Great. I'll be working on porting over changes from Geany's D
On 20/11/2014 08:02, Walter Bright wrote:
On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
If this kind of unsafe mixing wasn't allowed, or required explict casts
(to signify yes I know what I'm doing and I'm prepared to face the
consequences), I suspect that bearophile would be much
On 14/11/2014 21:52, David Nadlinger wrote:
On Friday, 14 November 2014 at 06:10:43 UTC, Rikki Cattermole wrote:
std.range.checks
For this, std.range.constraints would also be perfectly fine.
If it's not too late, can we change the name to std.range.traits? It
seems better as they can be
On 12/11/2014 15:36, Nick Treleaven wrote:
Seeing as the 'scope' attribute doesn't seem to be happening any time
soon, shouldn't the compiler reject static array slicing in @safe code?
The user is then forced to think about the operation, and put the code
in a @trusted delegate if they think it
On 12/11/2014 17:16, Marc Schütz schue...@gmx.net wrote:
On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:
For example, taking a mutable borrowed pointer for a variable means
you can't even *read* the original variable whilst the pointer lives.
I think no one would try to
On 09/11/2014 10:34, bearophile wrote:
If you just disallow that kind of operations indiscriminately, you
reduce a lot the usefulness of D (because fixed size = dynamic slice
array is a conversion useful in many cases) and probably force the
introduction of many casts, and I don't know if this
On 11/11/2014 18:01, bearophile wrote:
I agree it's a very important topic (more important/urgent than the GC,
also because it reduces the need of the GC). But I think Walter thinks
this kind of change introduces too much complexity in D (despite it may
eventually become inevitable for D once
On 06/11/2014 01:36, Shammah Chancellor wrote:
Is this fixed now?
How about:
alias compiles(alias expr) = __traits(compiles, expr);
I guess supporting that may be problematic (it's too liberal), so I
think we should have __compiles(expr) instead. It looks like a small
saving, but in
On 04/11/2014 14:18, Johannes Pfau wrote:
And as long as there is no other solution warnings are better than
simply ignoring the problem.
+1
But I think it's likely this check will be implemented in
Dscanner (https://github.com/Hackerpilot/Dscanner/issues/204) and
in the end it doesn't
On 04/11/2014 02:00, Walter Bright wrote:
You are glossing over and dismissing the problems with explicit casts,
and the problems with overloading, etc.
Can't solving any overloading problem be deferred? An incomplete
solution is better than nothing.
As for explicit casts, they are easily
On 02/11/2014 20:33, Walter Bright wrote:
On 11/2/2014 12:12 PM, bearophile wrote:
I think the free mixing of signed and unsigned integral values is not
a good
idea in D.
It's simply not workable to put a wall between them. Every proposal for
it has entailed various unfortunate, ugly, and
On 10/10/2014 22:19, monarch_dodra wrote:
Think the argument is that declaring `T t;` must be CTFE, which kind of
implies a T.init state (which may have non-deterministic values in the
presence of = void).
This is mostly for declaring things static, and the whole constructors
are run after the
On 01/10/2014 04:51, Vladimir Panteleev wrote:
On Tuesday, 30 September 2014 at 12:19:05 UTC, Nick Treleaven wrote:
On 23/09/2014 11:20, Nick Treleaven wrote:
Linking phobos.lib is the first time I've got OOM, I use Firefox
heavily. phobos.lib is only 10 MB, which is why I thought it odd that
On 23/09/2014 11:20, Nick Treleaven wrote:
Linking phobos.lib is the first time I've got OOM, I use Firefox
heavily. phobos.lib is only 10 MB, which is why I thought it odd that
linking uses well over 1 GB.
I'm now building Phobos 'myself' with win32.mak rather than with Digger,
and it seems
Hi,
I used to run the ddoc tests with no problem, but for the last month or
so I ran into problems building the d_do_test tool from latest Git dmd.
(As I didn't need the latest dmd at the time, I just used an older one
for a while).
Maybe I'm doing something wrong with my build setup for
On 27/09/2014 12:59, Nick Treleaven wrote:
# in dmd/test
$ make DMD=../src/dmd.exe QUIET=''
Building d_do_test tool
OS: win32
../src/dmd.exe -m32 -unittest -run d_do_test.d -unittest
/usr/bin/link: missing operand after `d_do_test,,nul,user32+kernel32/noi;'
Try `/usr/bin/link --help' for more
On 22/09/2014 19:59, Vladimir Panteleev wrote:
Firefox requires 4GB of memory to build.
Chromium requires 8GB of memory to build.
Android requires 16GB of memory to build.
Thanks for the info, I didn't realize.
If you want to work on big projects, you WILL need a decent computer.
I think
On 21/09/2014 18:43, Rainer Schuetze wrote:
I tried it on Windows and Digger does an amazing job at installing
dependencies. I think we should recommend it as the first thing to run
when trying to get your hands on building dmd/phobos.
+1
In case someone starts creating patches: Would it be
On 22/09/2014 10:35, Brian Schott wrote:
https://github.com/Hackerpilot/DCD/releases/tag/v0.4.0-beta1
Changelog at the above link. Let me know if and how you manage to break
it by filing an issue on Github.
I found this link to explain what DCD is ;-)
On 21/09/2014 03:35, deadalnix wrote:
- It is slow to compile.
Surely that's not an inherent property of Rust?
- Constraints too much the dev in some paradigms, which obviously
won't fit all area of programming.
Absolutely. The unique mutable borrow rule too often prevents even
On 12/09/2014 07:48, eles wrote:
On Thursday, 11 September 2014 at 23:05:19 UTC, Ali Çehreli wrote:
On 09/11/2014 12:08 PM, eles wrote:
The 'alias this = A' syntax did appear for one release as an
unintentional feature:
Having two syntaxes for alias makes everything looking worse and is an
On 12/09/2014 07:41, Ilya Yaroshenko wrote:
auto functionName(Range1, Range2)(Range1 r1, Ranger2)
scope {
import std.range; //imports are allowed
enum MaxLength = 1024; //enums are allowed
immutable A = [0.123, 0.456, 0.789]; // immutable and const are
allowed
bool isOdd
On 03/09/2014 13:51, ketmar via Digitalmars-d wrote:
anyway, comma-separated expressions must be eliminated. ok, let
'em appear in `for()` for a while, but nowhere else.
It's better to just disallow them where they are bug prone:
http://forum.dlang.org/thread/lgsel0$29fd$1...@digitalmars.com
On 19/08/2014 08:21, Jacob Carlborg wrote:
Did someone finish the changelog?
One thing missing is a Note on compiler conversions for unique
expressions, like:
https://github.com/D-Programming-Language/phobos/pull/2109/files#diff-0baf0d34bf308dc66e131c0e56e4239bR761
On 19/08/2014 15:09, Andrei Alexandrescu wrote:
There I fully agree. If they don't improve lifetime's usability, I don't
see Rust being adopted by average developers.
Could you please substantiate this with a couple of examples?
Here's an example I ran into playing with the last release.
On 18/08/2014 13:27, Maik Klein wrote:
If I do something like:
auto ptr = Unique(Foo);
Would the GC still be used, or would the resource be freed by the
destructor?
It uses GC allocation, but the memory will be freed deterministically:
{
Unique!Foo u = new Foo;
// u's destructor will
On 18/08/2014 13:55, Peter Alexander wrote:
I'm not sure what the status of std.typecons.Unique is. Last I heard it
had some issues, but I haven't tried it much myself.
It should work, but it is bug-prone without the @disable this(this) fix
in master. Unfortunately that won't make it into
On 14/08/2014 17:14, Nick Treleaven wrote:
I think it's not possible to have a documented unittest for a method
that isn't part of the parent template. This is necessary to prevent
template instantiation recursion sometimes.
Oops, my example wasn't recursive, I meant where the unittest has
On 14/08/2014 05:02, H. S. Teoh via Digitalmars-d wrote:
4) How much can you realistically test on a generic type argument T,
that you can't already cover with concrete types? I'm finding that the
per-instantiation behaviour of unittest blocks inside templated
structs/classes is rarely desired,
On 13/08/2014 08:59, Lars T. Kyllingstad wrote:
AFAIK, that documentation format is just a preview. I guess there are
more wrinkles that need to be ironed out before it can be considered
official.
Googling for 'process site:dlang.org' for me shows:
1. dlang.org/library/std/process.html
2.
On 05/08/2014 23:10, Meta wrote:
On Tuesday, 5 August 2014 at 19:31:08 UTC, H. S. Teoh via Digitalmars-d
wrote:
There are currently two Phobos PR's that implement essentially the same
functionality, but in slightly different ways:
I don't think either is particularly useful. This is something
On 27/07/2014 09:44, Alix Pexton wrote:
On 26/07/2014 4:31 PM, Nick Treleaven wrote:
Hi,
Ddoc doesn't seem to expand a macro near top of
http://dlang.org/hash-map.html:
// The $(CODE_HIGHLIGHT KeyType) is string
Which is weird because it expands it for 'remove' on this line not far
below it:
Hi,
Ddoc doesn't seem to expand a macro near top of
http://dlang.org/hash-map.html:
// The $(CODE_HIGHLIGHT KeyType) is string
Which is weird because it expands it for 'remove' on this line not far
below it:
b.remove(hello);
Maybe a bug in dmd?
Also, I build some dlang.org docs
On 19/07/2014 10:32, Kagamin wrote:
Try to define a constructor with parameters, then compiler won't
generate the default constructor, so the parameterless opCall won't be
hidden.
That only works for classes, not structs.
On 19/07/2014 01:31, Timon Gehr wrote:
auto createBuffer(T,alias size)(T[]
buf=(cast(T*)alloca(size))[0..size]){ return buf; }
alloca(T.sizeof * size)
On 17/07/2014 18:56, Dicebot wrote:
It has never worked properly (opCall never got called) and being a bad
style going against language design rationale it was completely banned.
More info: https://issues.dlang.org/show_bug.cgi?id=12124
Thanks for the link. We need a note in the changelog
On 17/07/2014 18:58, Dicebot wrote:
(for Unique probably disabling default constructor makes most sense)
I'm not sure about that, default construction is useful to be able to
delay resource creation:
Unique!S u1;
...
u1 = unique!S(); // factory function
To allow that but
Hi,
I'm trying to update std.typecons.Unique. I want to add a static opCall
with no arguments to simulate a nullary-argument constructor.
Unfortunately, with a recent dmd from Git, I get this (reduced code):
class Class {}
struct U
{
Class c;
this(A...)(A args)
if (A.length !=
On 17/07/2014 18:11, Nick Treleaven wrote:
opcall.d(24): Error: struct opcall.U static opCall is hidden by
constructors and can never be called
opcall.d(24):Please use a factory method instead, or replace all
constructors with static opCall.
I should mention that std.typecons.Unique
On 10/07/2014 19:03, Walter Bright wrote:
On 7/10/2014 9:00 AM, Nick Treleaven wrote:
On 09/07/2014 20:55, Walter Bright wrote:
Unique!(int*) u = new int; // must work
That works, it's spelled:
Unique!int u = new int;
I'm unconfortable with that design, as T can't be a class ref or a
On 09/07/2014 20:55, Walter Bright wrote:
here's the first one,
to disable postblit:
https://github.com/D-Programming-Language/phobos/pull/2308
BTW I updated that pull, should be less muddled now ;-)
More things that need to happen with Unique:
...
Unique!(int*) u = new int; // must
On 08/07/2014 23:40, Remo wrote:
What about the already present std.typecons.Unique?
Unfortunately there are a lot of /+Doesn't work yet+/ comments in
std.typecons.Unique code.
I think it was written a long time ago. I think much of those parts will
work now. I'm slowly going through them
Hi,
This recent proposal looks like it might clean up typical Rust function
signatures significantly:
https://github.com/aturon/rfcs/blob/lifetime-elision/active/-lifetime-elision.md
Some discussion here:
Hi,
A Perlin noise benchmark was quoted in this reddit thread:
http://www.reddit.com/r/rust/comments/289enx/c0de517e_where_is_my_c_replacement/cibn6sr
It apparently shows the 3 main D compilers producing slower code than
Go, Rust, gcc, clang, Nimrod:
https://github.com/nsf/pnoise#readme
I
On 20/06/2014 13:32, Nick Treleaven wrote:
It apparently shows the 3 main D compilers producing slower code than
Go, Rust, gcc, clang, Nimrod:
Also, it does appear to be using the correct compiler flags (at least
for dmd):
https://github.com/nsf/pnoise/blob/master/compile.bash
On 18/06/2014 21:20, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
writeln(obj.member?.nested?.val);
Optional chaining in swift is meant to be used more like this:
if let v = ptr?.attr?.getobj?()?.attr? {
On 19/06/2014 16:04, H. S. Teoh via Digitalmars-d wrote:
we really should call it
something else. failsafe sounds a bit too generic. What about
safeDeref or just deref?
fallback? It could have an optional argument to override init.
On 12/06/2014 18:30, Nick Treleaven wrote:
On 12/06/2014 17:59, bearophile wrote:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in
Phobos:
On 12/06/2014 16:57, simendsjo wrote:
Does any sane person use _ as a variable identifier and
then reference it?
I forgot that C gettext has a macro called _(), and this D version also
has it (which is available via dub):
https://github.com/NCrashed/dtext/blob/master/source/dtext.d#L115
On 12/06/2014 16:57, simendsjo wrote:
On 06/12/2014 05:46 PM, monarch_dodra wrote:
On Thursday, 12 June 2014 at 15:09:51 UTC, simendsjo wrote:
_ is an often used identifier for i don't care in many languages. The
following works:
foreach(_; 0..n)
One issue is that _ is still an actual
On 12/06/2014 17:59, bearophile wrote:
there is also this usage:
foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in
Phobos:
std/algorithm.d:foreach (i, _;
On 07/06/2014 16:39, monarch_dodra wrote:
Then, you are using the code:
.partition!(forest_invalid).sort.uniq.array;
The advantage of partition over filter is that partition is a
greedy inplace algorithm. But then, you go on to use uniq, which is
lazy, and requires array. I implemented a (very)
On 11/06/2014 14:45, Nick Treleaven wrote:
/** Copy up to r.length elements of src to r. */
auto refill(R, Input)(ref R r, Input src)
if (isRandomAccessRange!R isInputRange!Input)
Note this is related to:
std.algorithm.fill(Range1 range, Range2 filler)
Except that fill always fills all of
On 17/03/2014 03:58, Marco Leise wrote:
Am Sun, 16 Mar 2014 18:31:59 +
schrieb bearophile bearophileh...@lycos.com:
HeiHon:
byLineCopy or
byLineCopied
sounds natural for me (native german).
byLineCopy sounds good.
Bye,
bearophile
+1. Same reasoning as HeiHon gave.
Implemented and
On 09/05/2014 18:25, brad clawsie wrote:
The official mailing list has practically no mention of generics anymore.
I think it comes up fairly regularly, despite the ML regulars being very
anti-generics. This was posted just 2 months ago:
On Tuesday, 29 April 2014 at 17:11:50 UTC, Steven Schveighoffer
wrote:
On Tue, 29 Apr 2014 13:09:01 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
A recent discussion
https://github.com/D-Programming-Language/dmd/pull/3452
brought up a matter I'd forgotten - struct fields
On 25/04/2014 08:29, Matthias Walter via Digitalmars-d wrote:
size_t find(T[] Array,T Element)
{
find returns a size_t being a nonnegativ number.
return -1;
But here it returns -1.
For size_t and uint 'dmd -w' seems to allow returning literal -1, but
with ubyte I get:
On 21/04/2014 09:49, Lars T. Kyllingstad wrote:
I often wish private meant class private in D. I know, the usual
argument against this is that someone who writes a module usually has
full control of that module, but again, Phobos is an example of the
contrary. Each module has at least a dozen
401 - 470 of 470 matches
Mail list logo
