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 Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote:
That's exactly what I've been saying. For like, 9 years..
It looks like this:
https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
(contribution appreciated)
I've followed this thread since it was made as this has be
On Sunday, 18 February 2018 at 21:58:57 UTC, jmh530 wrote:
On Sunday, 18 February 2018 at 21:12:11 UTC, Martin Nowak wrote:
[snip]
Interesting reading. Thanks for the update.
Indeed, very interesting read and exactly the information I was
looking for! Thanks a lot Martin, I'm excited to se
On Saturday, 17 February 2018 at 23:43:07 UTC, Adam D. Ruppe
wrote:
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
Andrei mentioned at his DConf presentations is that the
runtime itself will be modified to not rely on the GC,
allowing for you to continue using features
On Saturday, 17 February 2018 at 19:32:50 UTC, bachmeier wrote:
On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell
wrote:
My understanding from the vision documents and what Andrei
mentioned at his DConf presentations is that the runtime
itself will be modified to not rely on the
uary 2018 at 14:25:41 UTC, Seb wrote:
On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell
wrote:
The garbage collector in druntime is now lazily initialized on
the first use:
https://github.com/dlang/druntime/pull/2057
(in master since a few days)
That's really nice to hear 2.079 is looking really cool!
On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None
of the projects that I found (derelict-vulkan, d-vulkan and
erupted) work.
Are there D bindings to Vulkan that actually work?
I had success using Vulkan in Univers
Hi everyone, it's been almost a year since I used D but I was
wanted to get back into it. I was checking the 2017 vision pages
and was wondering why there hasn't been a 2018H1 vision page but
also what the current status of being able to use D without a
garbage collector is?
It was noted in t
Replying to a couple of the comments here
"I don't know if it's a different expectation or a different
mindset or something else."
I'd like to think I'm fairly knowledgeable, but Yes, I expect
installing/configuring to be easy and quick, so I can get to the
actual programming. I expect solid d
I've recently started evaluating D, and I thought as a D newbie
(but 20 year game dev veteran) I should share the things I felt
were missing or unclear, so you can decide if you want to do
something to cater new users. So my first notes are
1. Reading about D online: There is a decent amount o
As someone learning D, I thought I would give my insight in how I
came to D.
My biggest reason for choosing D is the GC. I have come from Java
and don't quite believe that I'm ready to manage my own memory
throughout an entire program, but the ability to disconnect from
the GC is a great way
On Sunday, 8 May 2016 at 23:38:31 UTC, Jon D wrote:
I did a performance study on speeding up case conversion in
std.uni.asLowerCase. Specifics for asLowerCase have been added
to issue https://issues.dlang.org/show_bug.cgi?id=11229.
Publishing here as some of the more general observations may be
On Sunday, 8 May 2016 at 18:55:58 UTC, Pablo wrote:
This is part of the old dparse.d file:
private import std.string : ToString = toString ;
char[] string()
{
static if(str)
{
static if(is(T == char[]))
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
1 - 100 of 1195 matches
Mail list logo