On Saturday, 19 July 2014 at 06:13:10 UTC, Manu via Digitalmars-d
wrote:
Anyway, does anybody know a nice tidy way to do it?
Unfortunately the only way to create perfect forwarding functions
completely generically is still using an ugly string mixin that
generates the forwarding function. A
On Saturday, 19 July 2014 at 17:40:01 UTC, Andrei Alexandrescu
wrote:
On 7/19/14, 9:36 AM, Jakob Ovrum wrote:
On Saturday, 19 July 2014 at 06:13:10 UTC, Manu via
Digitalmars-d wrote:
Anyway, does anybody know a nice tidy way to do it?
Unfortunately the only way to create perfect forwarding
On Thursday, 17 July 2014 at 21:03:08 UTC, Walter Bright wrote:
Did you see my response?
I suggested recognizing in the parser:
( Identifier )
as a special case, in addition to using Parser::isDeclaration().
I just want to point out that this special case is lacking, and
will inevitably
We should talk about a design question surrounding binary search
with `canFind`/`find` and possibly other linear-search functions.
Currently we have binary search in Phobos as part of
std.range.SortedRange. Its interface is not compatible with
`canFind` or `find` - you can't simply wrap the
On Thursday, 24 July 2014 at 01:21:44 UTC, Jakob Ovrum wrote:
-snip-
Another point is that the range types of the two currently
available sorted containers - RedBlackTree and BinaryHeap - are
*not* instances of SortedRange. If algorithms working on sorted
ranges become a thing, it seems
On Thursday, 24 July 2014 at 07:01:09 UTC, Manu via Digitalmars-d
wrote:
I imagine that would be a compile error; the static if can't be
resolved
without knowing T, and prior to resolution of the static if, no
constructors exist.
Please lay out this kind of logic in a DIP so it can actually
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote:
Round of a formal review before proceeding to voting. Subject
for Phobos inclusion : http://wiki.dlang.org/Review/std.logger
authored by Robert Schadek.
First I want to say that I want this to be *the* logging library,
just as I always
On Thursday, 24 July 2014 at 23:01:56 UTC, Robert burner Schadek
wrote:
I do this lazily in a function, because having it global froze
std.concurrency and std.process unittest. I couldn't figure out
why.
It could still be initialized lazily, using `emplace`, ala
---
private static __gshared
On Thursday, 24 July 2014 at 23:40:56 UTC, Jakob Ovrum wrote:
How often have you seen a formatted log message logged in a
loop? I'd wager that happens quite often. Using `format` is a
no-go as it completely thrashes the GC, it needs to use
`formattedWrite` to write directly to the underlying
On Friday, 25 July 2014 at 09:39:23 UTC, Walter Bright wrote:
That can be special cased, too.
Seriously? Where does it end?
catch(MyTemplatedException!true) {
}
Parsing this as a proper type without a trailing identifier is a
nice feature that a lot of people use, unlike the ghastly catch
On Friday, 25 July 2014 at 23:12:33 UTC, Walter Bright wrote:
On 7/25/2014 3:56 PM, David Nadlinger wrote:
Let's just get rid of catch {} which encourages unsafe code
and be done with it.
We need to stop breaking code.
Either change breaks code. There's no evidence to support that
catch{}
On Thursday, 24 July 2014 at 21:08:58 UTC, Jonathan M Davis wrote:
On Thursday, 24 July 2014 at 01:26:48 UTC, Jakob Ovrum wrote:
On Thursday, 24 July 2014 at 01:21:44 UTC, Jakob Ovrum wrote:
-snip-
Another point is that the range types of the two currently
available sorted containers -
On Saturday, 26 July 2014 at 23:06:02 UTC, Andrew Godfrey wrote:
Thereafter can come sub-slice examples and so on.
Does this make sense?
Yes, the reference documentation is pretty terrible with naming
of various array concepts.
IIRC, when this was discussed in the past, a majority seemed to
On Sunday, 27 July 2014 at 08:49:43 UTC, Jonathan M Davis wrote:
As defined by the language, T[] is a dynamic array. As great as
the article is, it was wrong in its use of the terminology, and
that's what's caused a lot of the confusion and resulted in
arguments over the difference between a
On Sunday, 27 July 2014 at 12:03:05 UTC, Jonathan M Davis wrote:
Except that no concepts are being conflated. T[] is the dynamic
array. There's a block of memory managed by the GC underneath,
but it's completely hidden from the programmer. It is _not_ the
dynamic array. It's just a block of
On Tuesday, 29 July 2014 at 05:11:33 UTC, Dicebot wrote:
1) Yes / No for inclusion into std.experimental
If modules in std.experimental are completely free to make
breaking changes, then my vote is a clear yes.
I'm uncertain if std.experimental can carry its own weight in the
presence of
On Wednesday, 30 July 2014 at 13:10:35 UTC, Wyatt wrote:
Serious question: what exactly is supplemental documentation?
In my view, if it's good enough to be considered
documentation, it belongs in the documentation. Anything else
is just pussy-footing around.
Consider information like how
On Wednesday, 20 August 2014 at 21:26:55 UTC, Philippe Sigaud via
Digitalmars-d wrote:
If you want reference semantics but do not want to have
pointers in
your code, yes classes are your best choice.
Certainly the easiest, but I don't think it's always the best. If
light-weightedness is
On Tuesday, 26 August 2014 at 14:48:05 UTC, nezih wrote:
Hi everyone,
I am trying to create a 32-bit dll (on windows server 2012
64-bit) for an odbc driver, but no luck so far.
Are you using DMD32 with OPTLINK? If so, are you sure the first
exported symbol doesn't accidentally have a leading
On Tuesday, 26 August 2014 at 15:28:32 UTC, nezih wrote:
I use optlink and I use the latest dmd: DMD32 D Compiler
v2.066.0
And yes I see underscores in front of the exported symbol
names. What's the workaround? And I just verified that the
64-bit version doesn't have those leading underscores.
On Saturday, 30 August 2014 at 02:11:49 UTC, Dicebot wrote:
Jakob Ovrum
The *API* must support minimal dynamic memory allocation for
the normal execution path. However, theoretical *implementation*
changes that reduce
On Saturday, 30 August 2014 at 13:37:17 UTC, Dicebot wrote:
On Saturday, 30 August 2014 at 13:35:57 UTC, H. S. Teoh via
Digitalmars-d wrote:
How do the remaining issues break down into QoI that can be
deferred
to a future release? -- Andrei
What is QoI? I am not familiar with this
On Wednesday, 3 September 2014 at 22:23:48 UTC, Xavier Bigand
wrote:
Le 21/08/2014 15:20, seany a écrit :
I am starting this thread to quench my thirst for knowledge.
I notice, that the existing wrappers to other languages are:
C: D can natively interface to C
C++
On Sunday, 7 September 2014 at 21:02:16 UTC, John Colvin wrote:
bool g(int n) { ... }
f(arr, g);
This will fail if `g` is a function pointer, such as when `g` is
declared at module-level scope. In that case, it has to be
explicitly converted to a delegate:
---
import std.functional :
On Sunday, 7 September 2014 at 21:31:11 UTC, AsmMan wrote:
Thank you too. Btw, why the operator in this syntax? I used
to think ref keyword sort of C's T** and operator is
neeeded.. or is it because f can be a function called without
pass any parameter?
In D, the address-of operator has to
On Sunday, 7 September 2014 at 21:42:31 UTC, Jakob Ovrum wrote:
void bar(void function() a) {}
s/void function() a/int function() a/
On Monday, 8 September 2014 at 03:37:45 UTC, deadalnix wrote:
In fact the distinction is done by C and C++ only.
And by D.
On Monday, 8 September 2014 at 03:01:40 UTC, AsmMan wrote:
I got it. Why it doesn't works if foo is a method?
Taking the address of a method/member function yields a delegate,
not a function pointer. Delegates are fat pointers; they contain
a pointer to the function as well as a pointer to
On Monday, 8 September 2014 at 06:23:40 UTC, deadalnix wrote:
On Monday, 8 September 2014 at 05:04:21 UTC, Jakob Ovrum wrote:
Function pointers can be converted to delegates through a
simple wrapper function (which is how
std.functional.toDelegate achieves it), but delegates cannot
be wrapped
On Monday, 8 September 2014 at 15:55:53 UTC, monarch_dodra wrote:
A particularly relevant example of this issue is `RefCounted`:
This struct uses malloc to ref count an object, give a
deterministic life cycle, and avoid the GC. Yet, since malloc
can fail, it does this:
_store = cast(Impl*)
There is one massive blocker for `@nogc` adoption in D library
code: allocation of exception objects. The GC heap is an ideal
location for exception objects, but `@nogc` has to stick to its
promise, so an alternative method of memory management is
desirable if we want the standard library to
On Friday, 12 September 2014 at 09:53:45 UTC, Atila Neves wrote:
This happens to me all the time. I write a function, stick the
aforementioned attributes on as a default then let the compiler
tell me when I can't.
That happens a lot more often than I thought it would. Pretty
much anytime I
On Friday, 12 September 2014 at 13:11:19 UTC, Kagamin wrote:
On Friday, 12 September 2014 at 10:19:27 UTC, Jakob Ovrum wrote:
Further, `inout` does not support considering callback
parameters to be out parameters:
struct S
{
int* p;
inout(int)* foo() inout { return p; } // OK
void
On Friday, 12 September 2014 at 11:03:09 UTC, monarch_dodra wrote:
I think option b) is the right direction. However, I don't
think it is reasonable to have the catch code be responsible
for the cleanup proper, as that would lead to a closed design
(limited allocation possibilities).
On Friday, 12 September 2014 at 11:38:18 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 9/12/14, Jakob Ovrum via Digitalmars-d
digitalmars-d@puremagic.com wrote:
the chaining mechanism will
construct a self-referencing list that results in an infinite
loop when the chain is walked
Can we
On Friday, 12 September 2014 at 12:47:46 UTC, Vladimir Panteleev
wrote:
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
I can think of a couple of ways to go:
1) The most widely discussed path is to allocate exception
instances statically, either in global memory or TLS.
On Friday, 12 September 2014 at 16:33:50 UTC, Dmitry Olshansky
wrote:
Agreed.
I think that the total amount of live (not garbage) exceptions
on heap is small for any typical application. Thus just special
casing the hell out of exception allocation in the GC (and
compiler) is IMO perfectly
On Friday, 12 September 2014 at 21:36:31 UTC, Johannes Pfau wrote:
I think if we could avoid dynamic allocations for most
exceptions
completely that'd be better. IIRC some people said that
exceptions are
mainly slow because of memory allocation. So if we could avoid
that,
there are more
On Saturday, 13 September 2014 at 19:58:16 UTC, Kagamin wrote:
On Saturday, 13 September 2014 at 18:36:53 UTC, Timon Gehr
wrote:
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr
wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions,
On Saturday, 13 September 2014 at 08:19:10 UTC, Marc Schütz wrote:
On Friday, 12 September 2014 at 21:31:45 UTC, Johannes Pfau
wrote:
Am Fri, 12 Sep 2014 12:59:22 +
schrieb Marc Schütz schue...@gmx.net:
Related: Last time I checked the runtime caches unwinding or
stack trace information in
On Sunday, 14 September 2014 at 04:26:30 UTC, Andrei Alexandrescu
wrote:
On 9/13/14, 8:43 PM, Manu via Digitalmars-d wrote:
I agree. It should be the default in all cases, as unanimously
agreed by
this community, and overruled by Andrei post-implementation.
There was no unanimity. -- Andrei
On Monday, 15 September 2014 at 05:50:36 UTC, Andrei Alexandrescu
wrote:
and have it be either refcounted or classic depending on the
definition of String. With a user-defined String, you need:
String s = String(abc);
The following works fine:
RCString s = abc;
It will call RCString.this
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
wrote:
So, please fire away. I'd appreciate it if you used RCString in
lieu of string and note the differences. The closer we get to
parity in semantics, the better.
It should support appending single code units:
---
alias
On Monday, 15 September 2014 at 09:53:28 UTC, Robert burner
Schadek wrote:
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei
Alexandrescu wrote:
The road there is long, but it starts with the proverbial
first step. As it were, I have a rough draft of a
almost-drop-in replacement of string
On Monday, 15 September 2014 at 11:53:15 UTC, Robert burner
Schadek wrote:
On Monday, 15 September 2014 at 10:13:28 UTC, Jakob Ovrum wrote:
On Monday, 15 September 2014 at 09:53:28 UTC, Robert burner
I haven't found a single lock, is single threading by design
or is thread-safety on your
On Monday, 15 September 2014 at 12:47:08 UTC, Robert burner
Schadek wrote:
On Monday, 15 September 2014 at 12:11:14 UTC, Jakob Ovrum wrote:
There's no use of `shared`, so all data involved is TLS.
Then it must be made sure that send and receive work properly.
They do. They only accept
On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
wrote:
http://dpaste.dzfl.pl/817283c163f5
The test on line 267 fails on a 32-bit build:
rcstring.d(267): Error: cannot implicitly convert expression
(38430716820228232L) of type long to uint
Hosting it as a Gist on Github[1]
On Wednesday, 17 September 2014 at 02:57:03 UTC, Freddy wrote:
When you have separate 2 typedefs of the exact same type, they
are equal.While this maybe able to be solved with
Typedef!(Typedef!(...)) different modules typedef ing the same
type (most likely build-in types) would have their
On Wednesday, 17 September 2014 at 16:32:04 UTC, Dicebot wrote:
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack Applegame
wrote:
You can use module name and line number as unique tag.
This is exactly what I would have expected as default
behaviour. Is anyone aware why this counter
On Friday, 19 September 2014 at 04:37:22 UTC, Vladimir Panteleev
wrote:
Yes, listing them in robots.txt, which was what I suggested.
I'm not saying we should actually remove them from the website
:)
We already have /phobos-prerelease/ and /library-prerelease/ in
robots.txt:
On Friday, 19 September 2014 at 07:57:24 UTC, Dicebot wrote:
I am obviously in favor of simply calling recurrent mutable
exception chains illegal (probably even immutable ones until we
fix const correctness of druntime exception handling).
Reason is simple : it doesn't require any changes in
On Friday, 19 September 2014 at 11:14:06 UTC, Dicebot wrote:
On Friday, 19 September 2014 at 04:44:07 UTC, Jakob Ovrum wrote:
On Wednesday, 17 September 2014 at 16:32:04 UTC, Dicebot wrote:
On Wednesday, 17 September 2014 at 10:00:31 UTC, Jack
Applegame wrote:
You can use module name and line
On Saturday, 20 September 2014 at 14:31:36 UTC, Adam D. Ruppe
wrote:
How often do you store an exception reference anyway that
escapes a catch block? I think all this talk is overkill to
solve a non-problem in 99% of practice.
Correct me if I'm wrong, but aren't *all* exceptions in a
On Saturday, 20 September 2014 at 13:49:58 UTC, Marco Leise wrote:
Am Sat, 20 Sep 2014 06:32:38 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
[snip]
Um, why not use __FILE__ / __LINE__ (as default
On Friday, 3 October 2014 at 04:52:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 03 Oct 2014 04:40:53 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
The throw thing is rather stupid, as the scope statement can
call arbitrary function that can itself throw.
that's why
On Monday, 6 October 2014 at 16:55:39 UTC, monarch_dodra wrote:
For the sake of argument, do you have any examples where a
program has used chaining?
I use explicit chaining in a couple of my libraries, i.e. code
like:
---
try foo();
catch(FooException e)
{
throw new
On Saturday, 11 October 2014 at 03:41:08 UTC, Dicebot wrote:
I don't see critical objections so far and this will move to
voting stage this weekend. Please hurry up if you want to say
something bad :)
Attributes need to be applied thoroughly. Even if most uses will
be through the base class
On Monday, 13 October 2014 at 00:42:09 UTC, Brad Roberts via
Digitalmars-d wrote:
I know it's a tricky implementation, but let's focus on the
goal.. should Array be usable in @safe code?
Looks like the `RefCounted` dependency has to be made @safe first.
On Tuesday, 14 October 2014 at 01:47:10 UTC, Brad Roberts via
Digitalmars-d wrote:
That's why I asked the question I did. The core question isn't
about what the current implementation is or does but about
where it should end up. Should Array be usable in @safe code.
Well, I think it goes
On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
As there was quite some last moment feedback I am giving some
more time for me to research issues a bit and Robert to address
them :)
The Pareto Principle could be worth mentioning here. We were 80%
of the way to a quality
On Wednesday, 15 October 2014 at 09:25:07 UTC, Robert burner
Schadek wrote:
On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote:
As there was quite some last moment feedback I am giving some
more time for me to research issues a bit and Robert to
address them :)
No need, I fixed the
On Wednesday, 22 October 2014 at 06:42:06 UTC, Ali Çehreli wrote:
On 10/21/2014 11:06 PM, thedeemon wrote:
A[B] freshCleanAA;
aa = freshCleanAA;
(where A[B] denotes the type of aa)
That's it!
Alternative:
A[B] aa;
aa = aa.init;
Ali
`aa.init` is just `null`, which
On Wednesday, 22 October 2014 at 07:42:22 UTC, Jonathan M Davis
via Digitalmars-d wrote:
Well, the reality of the matter is that you can't truly clear
it safely,
though we could definitely get closer. The in operator gives
pointer access to
the internals, and the byKey and byValue may do the
On Friday, 31 October 2014 at 19:09:28 UTC, H. S. Teoh via
Digitalmars-d wrote:
Besides, the sink version basically allows encapsulation of an
output
range -- instead of calling x.toString(outputRange) you just
write:
x.toString((const(char)[] data) { outputRange.put(data); });
In
On Tuesday, 28 October 2014 at 22:44:32 UTC, Freddy wrote:
http://wiki.dlang.org/DIP67
Abstraction over the build-in associative array(one type of
range
for containers and another type for dynamic generators).
Plese criticize.
Any examples of what this actually accomplishes? Maybe an example
On Saturday, 1 November 2014 at 00:04:18 UTC, Jakob Ovrum wrote:
... opIndex and opBinaryRight are already container ...
Correction: opBinaryRight!in
On Saturday, 1 November 2014 at 05:27:16 UTC, Jonathan Marler
wrote:
No need for the extra function, just call:
x.toString((outputRange.put));
That doesn't work for a wide variety of possible cases, notably
when `put` is a function template or when the code depends on
std.range.put or some
On Saturday, 1 November 2014 at 17:35:37 UTC, David Nadlinger
wrote:
There is still a critical issue with std.experimental.logger
that would prevent it from being merged right now: The abuse of
@trusted all over the code.
Thank you. I was afraid I'd have to harp on it for the fourth
time...
On Friday, 7 November 2014 at 14:11:32 UTC, bearophile wrote:
(This is a partial repost from a recent D.learn thread.)
In Phobos we have SortedRange and assumeSorted, but I do find
them not very good for a common enough use case.
The use case is to keep a sorted array, keep adding items to
On Thursday, 5 February 2015 at 06:18:07 UTC, BlackEdder wrote:
On Thursday, 5 February 2015 at 06:03:38 UTC, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei
Alexandrescu wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are
On Saturday, 7 February 2015 at 01:55:27 UTC, Jonathan Marler
wrote:
Byte b;
b = 0;
b = 1;
b = 255;
b = -256;
b = 'a';
b = cast(const char)'a';
b = cast(immutable char)'a';
b = cast(byte)1;
b = cast(const byte)1;
b = cast(immutable byte)1;
b = cast(ubyte)1;
b =
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote:
...
Added to the review queue as a work in progress with relevant
links:
http://wiki.dlang.org/Review_Queue
On Thursday, 5 February 2015 at 11:06:39 UTC, Jakob Ovrum wrote:
On Thursday, 5 February 2015 at 11:04:41 UTC, Daniel Murphy
wrote:
Jakob Ovrum wrote in message
news:flxonctqqtzmtyint...@forum.dlang.org...
However, this would set a possibly disruptive precedent that
range algorithms must no
On Wednesday, 21 January 2015 at 18:26:11 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jan 21, 2015 at 07:14:09PM +0100, zeljkog via
Digitalmars-d wrote:
Maybe something like this can be added to Fobos:
template Iota(int start, int stop, int step = 1){
template tuple(T...){
On Tuesday, 20 January 2015 at 18:12:27 UTC, ketmar via
Digitalmars-d wrote:
Hello.
as there is no possibility to doing GC allocations in class
destructors, wouldn't it be nice to just force @nogc
attribute on
such dtors?
Classes don't have to be designed to be allocated on the GC heap.
On Thursday, 12 February 2015 at 12:59:39 UTC, Steven
Schveighoffer wrote:
I think given the necessity of the above (which was not
discussed or noticed in that bug report), we should add a way
to call the true destructor properly in the compiler.
-Steve
I think these do the right thing with
On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:
On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu
via Digitalmars-d wrote:
...is what took to get std.experimental.logger in Phobos.
https://github.com/D-Programming-Language/phobos/pull/1500
A time to celebrate! Many
On Thursday, 29 January 2015 at 19:46:03 UTC, Jakob Ovrum wrote:
Although the Github tags aren't always kept up to date, this
link might be useful when looking for patches that need review:
https://github.com/D-Programming-Language/phobos/labels/needs%20review
Of course, ditto for the other
On Thursday, 29 January 2015 at 13:42:15 UTC, Atila Neves wrote:
After this thread:
http://forum.dlang.org/thread/hapxxhusoniimfxie...@forum.dlang.org
I had some time today and headed over to Github to see if I
could help out. But I'm not sure what I can do if I don't have
the power to
On Tuesday, 6 January 2015 at 06:43:13 UTC, HaraldZealot wrote:
For my particular project (it binds with something like finite
state machine) I will write some counterpart of decode function
from std.utf. Future function will decode string backward,
return dchar and change index passed by
On Wednesday, 11 February 2015 at 08:21:40 UTC, Rikki Cattermole
wrote:
As long as the std.concept package get's good documentation, I
think its a damn good idea!
In the spirit of type concepts as a federation of types, not a
hierarchy of types, I think std.*.concept, such as
On Wednesday, 11 February 2015 at 05:39:59 UTC, H. S. Teoh wrote:
Jakob Ovrum has just submitted a PR to make (the current
version of)
RefCounted reject interfaces, since currently it doesn't do that
correctly (it refcounts the reference to the interface rather
than the
target object).
Given
On Wednesday, 11 February 2015 at 08:54:41 UTC, Jonathan M Davis
wrote:
We really haven't been using the
term concepts for anything in D, and instead have been heavily
using the
term traits for what you're talking about - e.g. isInputRange
is considered
to be a trait.
My opinion is the
On Wednesday, 11 February 2015 at 09:11:18 UTC, Jonathan M Davis
wrote:
We have a whole module full of them - std.traits - so we're
already using
that term in Phobos, whereas you won't find the term concepts
in there
anywhere. And you seem to be looking for exactly the same thing
except in
Preface
I'd like to start by saying that this is a relatively low-impact
enhancement in the short term, but should pay off in the long
term. It also requires very little effort, so it is low-hanging
fruit, although it requires some foresight to see the benefit.
On Monday, 9 February 2015 at 11:37:23 UTC, Jakob Ovrum wrote:
std.array.join is strongly pure (with appropriate template
arguments), so its return value is implicitly convertible to
immutable.
Err, implicitly convertible to *mutable*. It goes both ways.
On Monday, 9 February 2015 at 10:56:31 UTC, Dicebot wrote:
Consider this trivial snippet:
```D
import std.array : join;
void main()
{
auto s = join([ aaa, bbb, ccc ]);
pragma(msg, typeof(s));
}
```
It outputs string which stands for immutable buffer.
The following works as
On Monday, 9 February 2015 at 01:41:33 UTC, Walter Bright wrote:
Anyone interested in taking up this flag?
Is this idea different from the one in
std.internal.test.dummyrange?
On Monday, 9 February 2015 at 11:38:23 UTC, Jakob Ovrum wrote:
On Monday, 9 February 2015 at 11:37:23 UTC, Jakob Ovrum wrote:
std.array.join is strongly pure (with appropriate template
arguments), so its return value is implicitly convertible to
immutable.
Err, implicitly convertible to
On Thursday, 12 February 2015 at 04:18:06 UTC, Adam D. Ruppe
wrote:
On Thursday, 12 February 2015 at 04:08:23 UTC, Jakob Ovrum
wrote:
Is it possible to call the destructor or postblit constructor
directly
yes, they are available as obj.__dtor() and obj.__postblit();
But...
and will they
Consider the following:
---
struct S
{
~this() @safe {}
}
void foo() @safe
{
S s;
// OK
}
void bar() @safe
{
S s;
destroy(s);
// test.d(15): Error: safe function 'test.bar' cannot call
system function 'object.destroy!(S).destroy'
}
---
`destroy` is used in algorithms
On Thursday, 5 February 2015 at 10:36:34 UTC, Eduardo Pinho wrote:
Some assistance on understanding what is wrong here is greatly
appreciated.
There's definitely nothing wrong with your code.
I always thought foreach preferred opApply when available because
internal iteration can in theory
On Thursday, 5 February 2015 at 11:04:41 UTC, Daniel Murphy wrote:
Jakob Ovrum wrote in message
news:flxonctqqtzmtyint...@forum.dlang.org...
However, this would set a possibly disruptive precedent that
range algorithms must no longer use foreach on aggregate
types...
I think this
On Thursday, 5 February 2015 at 01:10:18 UTC, Andrei Alexandrescu
wrote:
On 2/4/15 5:06 PM, Matt Kline wrote:
Is there a JSON library that most other people are using
instead?
http://vibed.org has a good one. -- Andrei
http://code.dlang.org/packages/std_data_json
On Sunday, 22 March 2015 at 01:15:07 UTC, Andrei Alexandrescu
wrote:
I've left a comment recently at
https://github.com/D-Programming-Language/phobos/pull/3087.
So what's the deal with that? Whenever a new tool leaves some
trash, do we chalk a circle on the pavement around it?
Andrei
On Wednesday, 4 March 2015 at 20:37:20 UTC, Marc Schütz wrote:
On Wednesday, 4 March 2015 at 19:36:20 UTC, Ali Çehreli wrote:
On 03/04/2015 07:43 AM, Steven Schveighoffer wrote:
I believe destructors are not run when you throw inside a
constructor.
So plan to deallocate if the ctor throws:
a
On Sunday, 1 March 2015 at 01:40:40 UTC, Andrei Alexandrescu
wrote:
We have a few candidates for solutions, but wanted to open with
a good discussion first. So, how do you envision a way to
define and access mutable metadata for objects (including
immutable ones)?
Andrei
I don't think
On Sunday, 1 March 2015 at 15:40:06 UTC, Atila Neves wrote:
I've lost count now of how many times I've had to downgrade to
auto despite always wanting immutable or const. This doesn't
work:
auto reg = regex(`(foo)`);
const match = foo.matchAll(reg);
writeln(match.captures); //oops,
On Monday, 23 February 2015 at 01:38:35 UTC, Manu wrote:
On 23 February 2015 at 07:47, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 2/22/2015 8:36 AM, Manu via Digitalmars-d wrote:
I have no idea where to start.
Start by making a ref counted type and see what the
On Sunday, 22 February 2015 at 00:43:47 UTC, Manu wrote:
D's GC is terrible, and after 6 years hanging out in this
place, I
have seen precisely zero development on the GC front.
You must have missed RTInfo, Rainer's precise heap scanner and
Sociomantic's concurrent GC.
1 - 100 of 270 matches
Mail list logo
