On Monday, 15 October 2018 at 20:53:32 UTC, Manu wrote:
On Mon, Oct 15, 2018 at 1:05 PM Peter Alexander via
Digitalmars-d wrote:
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
1. A single producer, single consumer (SPSC) queue is
necessarily shared, but is only safe if there is one
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
Destroy...
What you describe sounds better than what we currently have.
I have at least two concerns:
1. A single producer, single consumer (SPSC) queue is necessarily
shared, but is only safe if there is one writing thread and one
rea
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
2. object may have shared methods; such methods CAN be called on
shared instances. such methods may internally implement
synchronisation to perform their function. perhaps methods of a
lock-free queue structure for instance, or operator over
On Friday, 12 October 2018 at 07:13:33 UTC, Russel Winder wrote:
On Thu, 2018-10-11 at 13:00 +, bachmeier via Digitalmars-d
wrote: […]
Suggestions?
My guess is that the reason they've heard of those languages
is because their developers were writing small projects using
Go and Rust, but n
On Friday, 21 September 2018 at 06:00:33 UTC, Walter Bright wrote:
I've learned this the hard way, and I've had to learn it
several times because I am a slow learner. I've posted this
before, and repeat it because bears repeating.
I find this is a great procedure for any sort of large
refacto
On Saturday, 8 September 2018 at 22:01:23 UTC, Manu wrote:
As I and others have suggested before; mixin expansion should
emit a `[sourcefile].d.mixin` file to the object directory,
this file should accumulate mixin instantiations, and perhaps
it would be ideal to also emit surrounding code for
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat
wrote:
On Saturday, 8 September 2018 at 08:07:07 UTC, Peter Alexander
wrote:
I'd love to know if anyone is making good use of @nogc in a
larger code base and is happy with it. Weka.io?
Not Weka but we are happy with @nog
On Friday, 7 September 2018 at 17:01:09 UTC, Meta wrote:
You are allowed to call "@gc" functions inside @nogc functions
if you prefix them with a debug statement, e.g.:
Thanks! I was aware that debug is an escape hatch for pure, but
didn't consider it for @nogc.
I've been thinking lately tha
I recently wrote a small program of ~600 lines of code to solve
an optimisation puzzle. Profiling showed that GC allocations were
using non-trivial CPU, so I decided to try and apply @nogc to
remove allocations. This is a small experience report of my
efforts.
1. My program does some initiali
On Thursday, 30 August 2018 at 16:57:05 UTC, Maksim Fomin wrote:
My point is somewhat different from expressed already here by
Jonathan. He speaks about whitelisting/blacklisting and that
the former model will always contain loopholes. In my view, the
reason is that memory safety in (essentiall
On Sunday, 26 August 2018 at 08:40:32 UTC, Andre Pany wrote:
In the whole discussion I miss 2 really important things.
If your product compiles fine with a dmd version, no one forces
you to update to the next dmd version. In the company I work
for, we set for each project the DMD version in th
I follow a number of official programming language accounts on
Twitter. It is a good way to keep up to date with what's
happening in those communities and I imagine many people do the
same thing.
Something I've noticed is that D is relatively silent on this
front. At least on Twitter, it give
gmail gives the reason: "Lots of messages from k3.1azy.net were
identified as spam in the past."
Not sure what can be done. Just an FYI.
On Monday, 20 August 2018 at 08:39:38 UTC, Andrey wrote:
On Sunday, 19 August 2018 at 11:11:56 UTC, rikki cattermole
wrote:
This is a news group not a forum.
The web interface is driven by DFeed and is written in D.
It has been designed to be very fast (quite a notable feature).
I see this ad
import std.algorithm, std.stdio;
@safe:
auto foo() {
int[6] xs = [0, 1, 2, 3, 4, 5];
return xs[].map!(x => x);
}
void main() {
writeln(foo());
}
https://run.dlang.io/is/qC7HUR
For me this gives:
[0, 0, -2132056872, 22008, 0, 0]
Which looks like its
On Saturday, 28 July 2018 at 08:37:25 UTC, Peter Alexander wrote:
The wiki still links to high-level vision for 2018 H1. We're
now nearly one month into H2. Is a H2 document in progress?
Bump
https://downforeveryoneorjustme.com/code.dlang.org
502 Bad Gateway
The wiki still links to high-level vision for 2018 H1. We're now
nearly one month into H2. Is a H2 document in progress?
On Sunday, 22 July 2018 at 19:42:45 UTC, Peter Alexander wrote:
void main() {
int[int[1]] aa;
aa[[2]] = 1;
assert([2] in aa);
}
---
This assertion fails in 2081.1. Is this a bug?
https://dpaste.dzfl.pl/d4c0d4607482
https://issues.dlang.org/show_bug.cgi?id=19112
void main() {
int[int[1]] aa;
aa[[2]] = 1;
assert([2] in aa);
}
---
This assertion fails in 2081.1. Is this a bug?
https://dpaste.dzfl.pl/d4c0d4607482
On Sunday, 12 July 2015 at 12:14:31 UTC, Ola Fosheim Grøstad
wrote:
Yet, D is currently not in a strong position for mobile apps or
web servers.
Mobile apps: I agree.
Web servers: Why not?
What do you think about the future for D in the web service
space?
It seems like a space where D has
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu wrote:
This is a matter with some history behind it. In C, malloc(0)
always returns a new, legit pointer that can be subsequently
reallocated, freed etc.
Is the invariant malloc(0) != malloc(0) the only thing that makes
0 a special c
On Sunday, 17 May 2015 at 20:31:50 UTC, deadalnix wrote:
On Sunday, 17 May 2015 at 14:13:03 UTC, Peter Alexander wrote:
On Friday, 15 May 2015 at 16:36:29 UTC, Andrei Alexandrescu
wrote:
This is a matter with some history behind it. In C, malloc(0)
always returns a new, legit pointer that can
On Monday, 11 May 2015 at 15:45:38 UTC, Andrei Alexandrescu wrote:
On 5/10/15 5:58 AM, Timon Gehr wrote:
Keep in mind that currently, entire regions of memory can
change from
mutable to immutable implicitly when returned from pure
functions.
Furthermore, as Michel points out, the ways 'immutabl
On Sunday, 22 February 2015 at 14:49:37 UTC, Marc Schütz wrote:
On Sunday, 22 February 2015 at 14:41:43 UTC, Peter Alexander
wrote:
On Sunday, 22 February 2015 at 04:19:32 UTC, deadalnix wrote:
On Saturday, 21 February 2015 at 22:13:09 UTC, Peter
Alexander wrote:
malloc+free can be trusted if
On Sunday, 22 February 2015 at 04:19:32 UTC, deadalnix wrote:
On Saturday, 21 February 2015 at 22:13:09 UTC, Peter Alexander
wrote:
malloc+free can be trusted if wrapped in something like a ref
counted pointer, no?
Foo bazoom;
class Foo {
void bar() {
bazoom = this;
}
}
void
On Sunday, 22 February 2015 at 07:11:24 UTC, deadalnix wrote:
On Sunday, 22 February 2015 at 02:27:30 UTC, Peter Alexander
wrote:
On Sunday, 22 February 2015 at 01:24:09 UTC, Almighty Bob
wrote:
a += b; // Compiles with no ERROR!
Please tell me that's a bug?
Not a bug. From spec:
On Sunday, 22 February 2015 at 02:35:02 UTC, Adam D. Ruppe wrote:
On Sunday, 22 February 2015 at 02:27:30 UTC, Peter Alexander
wrote:
Seems questionable to me. Anyone know the rationale?
I actually agree it is a bit questionable, but I think the
difference is += is, conceptually at least
On Sunday, 22 February 2015 at 02:15:29 UTC, Almighty Bob wrote:
"Assign Expressions:
The right operand is implicitly converted to the type of the
left operand"
which quite clearly is not the case since...
a=b; // causes an error. but..
a+=b; // does not.
float does not *implicitly* convert
On Sunday, 22 February 2015 at 01:24:09 UTC, Almighty Bob wrote:
a += b; // Compiles with no ERROR!
Please tell me that's a bug?
Not a bug. From spec:
http://dlang.org/expression.html#AssignExpression
Assignment operator expressions, such as:
a op= b
are semantically equivalent to:
a = ca
On Saturday, 21 February 2015 at 20:13:26 UTC, deadalnix wrote:
On Saturday, 21 February 2015 at 19:38:02 UTC, Peter Alexander
wrote:
@safe @nogc
:-)
(I rewrote the post a few times. Originally I just wrote "mark
main @safe @nogc and you're fine", but I think it's a b
On Saturday, 21 February 2015 at 18:42:54 UTC, deadalnix wrote:
On Saturday, 21 February 2015 at 18:06:57 UTC, Peter Alexander
wrote:
On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
Now,some people think D is a 'Memory safety depends entirely
on GC' system Language,w
On Saturday, 21 February 2015 at 10:00:07 UTC, FrankLike wrote:
Now,some people think D is a 'Memory safety depends entirely on
GC' system Language,what do you think?
It's kind of right, at the moment, since @nogc D is still quite
difficult to use, mostly due to exceptions and library artifact
On Saturday, 14 February 2015 at 19:39:44 UTC, Andrei
Alexandrescu wrote:
Peter, could you please take this?
Yep, I have some time.
https://issues.dlang.org/show_bug.cgi?id=14183
On Friday, 13 February 2015 at 18:32:35 UTC, Andrei Alexandrescu
wrote:
* Perhaps rename groupBy to chunkBy. People coming from SQL and
other languages might expect groupBy to do hash-based grouping.
Agreed.
* The unary function implementation must return for each group
a tuple consisting of
On Saturday, 7 February 2015 at 15:02:43 UTC, Andrei Alexandrescu
wrote:
On 2/7/15 6:35 AM, Daniel Murphy wrote:
"Peter Alexander" wrote in message
news:uiqnamficseklfowm...@forum.dlang.org...
I'm writing a blog post about why we don't need rvalue
references in
D. It s
On Saturday, 7 February 2015 at 14:46:55 UTC, Daniel Murphy wrote:
NRVO isn't required for correct semantics, as structs can be
moved with bitcopy.
Yes, you're right. I suppose what I mean is that it should be
guaranteed that returning a local Lvalue by value should always
be moved to the cal
I'm writing a blog post about why we don't need rvalue references
in D. It seems that we rely on NRVO being performed, not just as
an optimization, but for correct semantics (e.g. for objects
without destructors or postblits). This doesn't appear to be
documented anywhere.
Is it meant to be p
On Tuesday, 3 February 2015 at 23:23:35 UTC, deadalnix wrote:
We have an attribute system, why make this a pragma ?
Rationale is in the DIP: "These are not attributes because they
should not affect the semantics of the function. In particular,
the function signature must not be affected."
On Saturday, 24 January 2015 at 14:53:02 UTC, Andrei Alexandrescu
wrote:
On 1/24/15 3:50 AM, Peter Alexander wrote:
On Friday, 23 January 2015 at 18:22:08 UTC, zeljkog wrote:
On 23.01.15 19:13, Andrei Alexandrescu wrote:
On 1/23/15 10:05 AM, zeljkog wrote:
On 23.01.15 18:48, H. S. Teoh via
On Friday, 23 January 2015 at 18:22:08 UTC, zeljkog wrote:
On 23.01.15 19:13, Andrei Alexandrescu wrote:
On 1/23/15 10:05 AM, zeljkog wrote:
On 23.01.15 18:48, H. S. Teoh via Digitalmars-d wrote:
I think what he's trying to do is to call a function that
returns a
delegate, and use that deleg
On Sunday, 11 January 2015 at 23:54:16 UTC, Andrei Alexandrescu
wrote:
On 1/11/15 3:38 PM, Robert burner Schadek wrote:
what about making it multi column like on
http://en.cppreference.com/w/
A nice possibility, though I do like the entity + blurb layout.
-- Andrei
Most of those blurbs add
On Saturday, 10 January 2015 at 20:19:14 UTC, Andrei Alexandrescu
wrote:
groupBy is an important primitive for relational algebra
queries on data. Soon to follow are operators such as
aggregate() which is a sort of reduce() but operating on ranges
of ranges.
GroupBy is a very important range.
I asked in D.learn, but didn't get a satisfactory answer. I think
this may be unachievable in the current language.
Consider:
auto foo(T)(T a) {
T b; // Error: cannot access frame pointer of main.X
b.data[] = 1;
return b;
}
void main() {
struct X {
On Wednesday, 7 January 2015 at 23:31:30 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via
Digitalmars-d wrote:
https://issues.dlang.org/show_bug.cgi?id=13806
For the lazy: BitArray has an init() method, which hides the
property
https://issues.dlang.org/show_bug.cgi?id=13806
For the lazy: BitArray has an init() method, which hides the
property BitArray.init
This, or something similar, appears every few months. Walter has
said in the past that the ability to override init is a feature.
As far as I can tell, no one is
In C++ head const is stripped for ifti, but we can't do that in
general in D due to transitivity. I'd like for it to happen when
it can though, particularly for scalar types.
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via
Digitalmars-d wrote:
I've been working on a pretty comprehensive module for dealing
with
colours in various formats and colour spaces and conversions
between
all of these.
It seems like a hot area for duplicated effort, since anything
that
You need to overload on const, and also pass in a correctly typed
function as the argument (you can't call a function with a
mutable parameter with a const object.
import std.stdio;
class Hugo {
public int x = 42;
void blah(void function(Hugo h) f) {
f(this);
}
// OVERLOAD
voi
On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu
wrote:
Very little breakage I can think of. Ranges usually don't own
their payload.
I'm thinking more about higher order ranges, e.g. take, filter,
cycle, retro; over a mutable range with ref front. Even if the
underlying range
On Sunday, 28 December 2014 at 03:09:20 UTC, Andrei Alexandrescu
wrote:
Please comment: http://wiki.dlang.org/DIP25
This seems like it may be painful (in terms of breaking existing
code):
"Member functions of structs must qualify this with inout if they
want to return a result by ref that w
On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote:
Just wondering what the general sentiment is.
For me it's these 3 points.
- tuple support (DIP32, maybe without pattern matching)
- working import, protection and visibility rules (DIP22, 313,
314)
- finishing non-GC memory ma
On Friday, 5 December 2014 at 23:25:11 UTC, Walter Bright wrote:
https://www.reddit.com/r/d_language/
It's the default, and is kinda boring. Compare with the rust
subreddit:
http://www.reddit.com/r/rust/
While not great, it's much better than ours.
We don't need the subreddit. We have
On Monday, 24 November 2014 at 14:20:02 UTC, bearophile wrote:
Peter Alexander:
Chunks.save should also be const, so result.save.{...} should
work.
But it doesn't. Should I have to file two bug reports (ERs) on
iota and chunks?
I suppose chunks should be inout, because you might
On Monday, 24 November 2014 at 12:20:40 UTC, bearophile wrote:
Peter Alexander:
Should be able to do:
assert(result.save.all!(x => x < 10));
But iota's save isn't const, so you can't (that's a bug).
Mine was just an example of the general problem, another
ex
Should be able to do:
assert(result.save.all!(x => x < 10));
But iota's save isn't const, so you can't (that's a bug).
On Wednesday, 22 October 2014 at 11:10:35 UTC, Ola Fosheim
Grøstad wrote:
[snip]
These kinds of optimizations are very difficult to achieve in a
low level backend, but you really need them in order to do
generic programming properly.
A simple start would be to not provide term rewriting as a
On Thursday, 16 October 2014 at 08:45:18 UTC, Chris wrote:
I think there is no easy way of finding out where the
optimization goes wrong. But should this happen at all, i.e.
does it point to a flaw in my program or is it a compiler bug?
I like to think it's the latter, after all the program wor
Looks like Bjarne has proposed UFCS for C++
http://isocpp.org/files/papers/N4174.pdf
No mention of D though...
On Friday, 10 October 2014 at 21:11:20 UTC, Ola Fosheim Grostad
wrote:
On Friday, 10 October 2014 at 09:00:17 UTC, Peter Alexander
wrote:
You can't have simple, expressive, and low level control.
Why not?
It's just something I believe from experience.
The gist of my reasoning
On Friday, 10 October 2014 at 00:36:45 UTC, deadalnix wrote:
Is this the politically correct wy to say "we don't care about
simplicity anymore!" ?
Heh. I don't think so. We've just rebalanced our priorities.
You can't have simple, expressive, and low level control. D1 was
simple but lacking i
On Wednesday, 8 October 2014 at 19:44:04 UTC, Joakim wrote:
What does this have to D? Well, the phenomenon he describes
probably has a big effect on D's adoption even today, as he was
talking about the spread of programming languages, ones we use
to this day. Certainly worth thinking about, a
On Wednesday, 8 October 2014 at 20:15:51 UTC, Steven
Schveighoffer wrote:
On 10/8/14 4:10 PM, Andrei Alexandrescu wrote:
On 10/8/14, 1:01 PM, Andrei Alexandrescu wrote:
That's a bummer. Can we get the compiler to remove the "if
(__ctfe)"
code after semantic checking?
Or would "static if
On Tuesday, 7 October 2014 at 20:13:32 UTC, Jacob Carlborg wrote:
I didn't look at any source code to see what "new" is actually
allocating, for example.
I did some random sampling, and it's 90% exceptions, with the
occasional array allocation.
I noticed that a lot of the ~ and ~= complaints
On Tuesday, 7 October 2014 at 16:23:19 UTC, grm wrote:
2.) There seems to be a problem with repeated alarms:
When viewing the page source, this link shows up numerous
times. See
https://github.com/D-Programming-Language//phobos/blob/d4d98124ab6cbef7097025a7cfd1161d1963c87e/std/conv.d#L688
Tha
On Wednesday, 1 October 2014 at 14:16:38 UTC, bearophile wrote:
Max Klyga:
https://www.youtube.com/watch?v=TH9VCN6UkyQ
A third talk (from another person) about related matters:
https://www.youtube.com/watch?v=rX0ItVEVjHc
He doesn't use RTTI, exceptions, multiple inheritance, STL,
templates,
On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau
wrote:
What if I don't want automated memory _management_? What if I
want a
function to use a stack buffer? Or if I want to free manually?
Agreed. This is the common case we need to solve for, but this is
memory allocation, not mana
On Sunday, 28 September 2014 at 00:13:59 UTC, Andrei Alexandrescu
wrote:
On 9/27/14, 3:40 PM, H. S. Teoh via Digitalmars-d wrote:
If we can get Andrei on board, I'm all for killing off
autodecoding.
That's rather vague; it's unclear what would replace it. --
Andrei
No autodecoding ;-)
Spec
On Sunday, 28 September 2014 at 00:58:00 UTC, Walter Bright wrote:
On 9/27/2014 4:27 PM, Peter Alexander wrote:
I've now filed a bug.
https://issues.dlang.org/show_bug.cgi?id=13547
Thanks for filing the bug report. I was going to raise its
priority, and found you'd already done
Just had an unfortunate exchange on Twitter
https://twitter.com/bitshifternz/status/515998608009601024
Him: "isn't D garbage collected? That would make it a non-starter
for me."
Me: "it's optional. malloc/free are available and we'll have
allocators soon that can hook into std lib."
Him: "
On Saturday, 27 September 2014 at 23:04:00 UTC, Walter Bright
wrote:
On 9/27/2014 3:52 PM, bearophile wrote:
There is no char auto decoding in this program, right?
Notice the calls to autodecoding 'front' in the assembler dump.
I think you're imagining things Walter!
There's no auto-decodin
On Saturday, 27 September 2014 at 20:57:53 UTC, Walter Bright
wrote:
From time to time, I take a break from bugs and enhancements
and just look at what some piece of code is actually doing.
Sometimes, I'm appalled.
Me too, and yes it can be appalling. It's pretty bad for even
simple range cha
On Thursday, 25 September 2014 at 22:52:39 UTC, Sean Kelly wrote:
On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:
As a fellow game dev:
I don't agree with him about RAII, I find it useful
He kind of has a point about exceptions, I'm not big on them
...
He goes on about "freeing fre
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei
Alexandrescu wrote:
On 9/25/14, 4:33 AM, Kagamin wrote:
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright
wrote:
So how do you tell it to call myfree(p) instead of free(p) ?
Maybe stock malloc/free is enough for him?
That ki
On Thursday, 25 September 2014 at 09:58:31 UTC, Walter Bright
wrote:
On 9/25/2014 2:27 AM, Walter Bright wrote:
Looks like he reinvented D dynamic arrays at 1:02. Sigh.
At 1:16 he gives credit to Go for the -> and . becomes . thing.
Says its great.
And he wants:
And ...
... he's spe
On Tuesday, 23 September 2014 at 18:52:13 UTC, H. S. Teoh via
Digitalmars-d wrote:
1) Change lookup rules so that symbols pulled in by local
import are
found last. Walter has stated that he disagrees with this
approach
because it complicates symbol lookup rules.
This.
On Sunday, 21 September 2014 at 19:36:01 UTC, Nordlöw wrote:
On Friday, 19 September 2014 at 15:32:38 UTC, Andrei
Alexandrescu wrote:
Please chime in with thoughts.
Why don't we all focus our efforts on upgrading the current GC
to a state-of-the GC making use of D's strongly typed memory
mod
On Sunday, 21 September 2014 at 20:05:57 UTC, Walter Bright wrote:
I don't know what mental model people have for how lookups
work, but the above algorithm is how it actually works.
My mental model for local imports is "it's the same as module
level imports, except the symbols are only availab
On Wednesday, 17 September 2014 at 22:42:27 UTC, deadalnix wrote:
On Wednesday, 17 September 2014 at 16:25:57 UTC, Dicebot wrote:
I had impression that general rule is "most inner scope takes
priority" (with base classes being one "imaginary" scope above
the current one). Are there any actual i
tion it here to avoid
scope creep in what Peter Alexander (and others) might be
working on.
That sounds great. I'm not planning anything grand with this. I'm
just going to get the already exiting benchmark framework working
with dmd, ldc, and gdc; and put it on github so people can
c
On Wednesday, 17 September 2014 at 14:59:48 UTC, Andrei
Alexandrescu wrote:
Awesome. Suggestion in order to leverage crowdsourcing: first
focus on setting up the test bed such that adding benchmarks is
easy. Then you and others can add a bunch of benchmarks.
Yep, sounds like a plan.
On Wednesday, 17 September 2014 at 06:59:40 UTC, bearophile wrote:
Andrei Alexandrescu:
https://issues.dlang.org/show_bug.cgi?id=13487
If the upload conditions and site are sufficiently good I am
willing to offer some implementations in D and to keep them
updated. I suggest to add two D ver
On Tuesday, 16 September 2014 at 22:26:48 UTC, Isaac Gouy wrote:
On Tuesday, 16 September 2014 at 21:04:59 UTC, Peter Alexander
wrote:
-snip-
I'll take a stab at it. Will give me something to do on my
commute :-) (assuming his scripts work, or can be made to
work on OS X).
It&
On Tuesday, 16 September 2014 at 17:32:39 UTC, Andrei
Alexandrescu wrote:
On 9/16/14, 9:44 AM, Kagamin wrote:
I'd say, run the damned benchmark for C and D. C would setup
performance
scale. What would be interesting is to see, how compiler
switches affect
performance, especially assert vs relea
On Sunday, 14 September 2014 at 09:42:28 UTC, deadalnix wrote:
• Specifies how things are done (implementation)
I'm not sure what this one mean precisely.
The way I interpret it is that (for template constraints), they
are quite clumsy for specifying preferences between overloads,
e.g.
voi
On Saturday, 13 September 2014 at 22:25:57 UTC, Walter Bright
wrote:
Yeah, well, we have many years of experience with "static if"
and no apocalypse has yet happened.
Well, we are yet to define "static if" when it comes to tricky
cases, i.e. cases where static ifs and mixins have
interdepende
On Thursday, 11 September 2014 at 19:08:27 UTC, eles wrote:
See this:
http://forum.dlang.org/post/kfdkkwikrfvaukhct...@forum.dlang.org
"alias" supports two syntaxes, one of them specifically to
address writing things like alias A this.
That's inconsistent. I agree not the most urgent thing i
On Monday, 8 September 2014 at 15:25:11 UTC, Timon Gehr wrote:
On 09/08/2014 10:51 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
" wrote:
What kind of syntactical sugar do you feel is missing in D?
int square(int x)=>x*x;
Unfortunately we still can't just write:
alias square = x => x * x;
but
On Wednesday, 10 September 2014 at 20:01:40 UTC, Joakim wrote:
Orvid, where's that new GC when we need it? ;)
Andrei posted this in the reddit thread:
"OK that does it. I'm going to redesign and implement D's tracing
garbage collector using the core allocator I wrote a short while
ago.
Fat
On Friday, 29 August 2014 at 02:21:07 UTC, Andrei Alexandrescu
wrote:
Dear community, are you ready for this?
Yes.
This is a significant change of behavior. Should we provide a
temporary flag or attribute to disable it?
I don't think so, it will just hinder adoption. If people don't
want i
On Sunday, 24 August 2014 at 01:06:31 UTC, Andrei Alexandrescu
wrote:
I'm thinking of relaxing the definitions to all types that
fulfill the following requirements:
* are random access ranges
* element type is some character
* offer .ptr as a @system property that offers a pointer to the
first
Welcome!
1. What is the current support for calling C/C++ free functions
from D? What level of mangling is supported? What data types
can be passed without translation from D to C/C++?
3. How can a C++ object be used from D? Can C++ methods be
called from D? The question applies to value typ
On Thursday, 21 August 2014 at 05:24:13 UTC, Artur Skawina via
Digitalmars-d wrote:
While D's `ref` is a hack, it's /already/ part of the function
type/signature.
The return type of a function is /already/ (ie in the D
dialects supported
by recent frontend releases) determined from *all* returne
On Wednesday, 20 August 2014 at 14:52:59 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 20 Aug 2014 14:44:40 +
Peter Alexander via Digitalmars-d
wrote:
Well, the return type is already the common type of all return
paths
no, it's not. the return type will be taken from the first
r
On Tuesday, 19 August 2014 at 23:56:12 UTC, ketmar via
Digitalmars-d wrote:
first: compilation speed. compiler can stop looking at function
just
after the first 'return'.
No, it still has to check the other returns for errors anyway.
second: it's easier to human to determine the actual return
Consider these two functions:
auto ref foo(ref int x) {
if (condition) return x;
return 3;
}
auto ref bar(ref int x) {
return condition ? x : 3;
}
At a first glance, they appear to be equivalent, however foo is a
compile-time error "constant 3 is not an lvalue" while bar
compiles fine a
On Tuesday, 19 August 2014 at 14:40:44 UTC, Andrei Alexandrescu
wrote:
If there's a strong D community in Europe I could look into
holding the next DConf at Facebook London. A kind of "proof"
would be awesome. -- Andrei
I like this idea :-)
On Monday, 18 August 2014 at 12:06:27 UTC, Kagamin wrote:
On Monday, 18 August 2014 at 10:01:59 UTC, maik klein wrote:
Does a GC still have advantages over heap allocations that do
not need to be reference counted such as the unique_ptr in c++?
Isn't unique_ptr unique? What to do when the obje
On Monday, 11 August 2014 at 03:29:56 UTC, Andrei Alexandrescu
wrote:
[...] can be implemented generically for ranges that offer
front as a reference:
bool sameFront(R1, R2)(R1 r1, R2 r2) {
return &r1.front == &r2.front;
}
This doesn't work for ranges that visit the same element twice,
e.g.
On Saturday, 16 August 2014 at 02:23:45 UTC, Tofu Ninja wrote:
Would this only be usable be usable for templates already
instantiated in the c++ object file you were linking with?
Yes, it has to be. You would need to use C++'s explicit template
instantiation to create an object file with all t
1 - 100 of 1058 matches
Mail list logo
