On Thursday, 15 May 2014 at 00:00:37 UTC, Walter Bright wrote:
On 5/14/2014 3:42 PM, Brian Schott wrote:
If malloc can never be considered pure, even when hidden
behind an allocator,
It cannot be pure as long as it can fail.
why can it be considered pure when hidden behind the GC?
Because
On Wednesday, 14 May 2014 at 22:42:47 UTC, Brian Schott wrote:
What is the plan for the "pure"-ity of memory management?
Right now the "new" operator is considered to be pure even
though it is not, but related functinos like malloc,
GC.addRange, GC.removeRange, and others are not.
This preve
On Wednesday, 14 May 2014 at 18:05:44 UTC, monarch_dodra wrote:
A little while ago, Steven Schveighoffer started a thread
called "D UFCS anti-pattern". The conversation started in
regards to "how can a generic algorithm be replaced by a custom
type". In particular (in my original use case) "ret
On Tuesday, 13 May 2014 at 06:54:08 UTC, Chris Piker wrote:
On Wednesday, 10 January 2007 at 03:57:58 UTC, Kirk McDonald
wrote:
Knowing that D already has (by my count) three command-line
argument parsers, I have gone and written my own, anyway. As
with at least one other of the parsers that I'
On Wednesday, 7 May 2014 at 18:29:23 UTC, Brad Anderson wrote:
Unless I'm misunderstanding it should be as simple as:
wchar[100] stackws; // alloca() if you need it to be
dynamically sized.
A slice of this static array behaves just like a slice of a
dynamic array.
But you should avoid slic
On Tuesday, 6 May 2014 at 19:18:08 UTC, Wyatt wrote:
On Tuesday, 6 May 2014 at 18:02:46 UTC, John Colvin wrote:
It never occurred to you that people's libraries would be
published as part of a centralised repository with a tool that
manages dependencies?
Hate to be the cynic, but how in the
On that note,
http://code.dlang.org/?sort=updated&category=library.std_aspirant.
However, the community is starting to standardize around Dub as
the standard package manager. Dub makes downloading a package as
easy as editing a JSON file (and it scales such that you can
download a project of any size this way). Did Python have a
proper package manager before this idiom aros
On Sunday, 4 May 2014 at 10:04:12 UTC, bearophile wrote:
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language visible
On Sunday, 4 May 2014 at 08:34:20 UTC, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a
possible good candidate due to its static typing and related
features.
On Saturday, 3 May 2014 at 01:17:36 UTC, Jonathan M Davis via
Digitalmars-d wrote:
The problem that some of what gets warned about is _not_
actually a problem.
If it always were, it would be an error. So, unless you have
control over
exactly what gets warned about and have the ability to disable
On Friday, 2 May 2014 at 21:40:09 UTC, Jonathan M Davis via
Digitalmars-d wrote:
True, that is a problem. But if folks really want the warnings,
they can go to the extra effort.
Why are we making people go to extra effort to get lint-like
functionality if we want it to be something that everyo
On Friday, 2 May 2014 at 18:32:13 UTC, Dylan Knutson wrote:
Correct me if I'm wrong here, but this seems really similar to
how Rust does owned pointers and move semantics. Or is there a
large conceptual difference between the two that I'm missing?
I believe that the issues that people are brin
On Friday, 2 May 2014 at 06:51:49 UTC, deadalnix wrote:
An isolated is consumed when:
- it is returned
- it is passed as argument
- it is assigned to another island
This will not work well with UFCS.
isolated int[] ints = new int[](10);
//put looks like a member function, but
//this desugar
On Wednesday, 30 April 2014 at 22:14:44 UTC, Walter Bright wrote:
On 4/30/2014 2:34 PM, Meta wrote:
On Wednesday, 30 April 2014 at 21:04:19 UTC, Walter Bright
wrote:
On 4/30/2014 1:38 PM, Meta wrote:
Also, while we're thinking about static unittest, what about
contracts? I've
seen
On Wednesday, 30 April 2014 at 21:04:19 UTC, Walter Bright wrote:
On 4/30/2014 1:38 PM, Meta wrote:
Also, while we're thinking about static unittest, what about
contracts? I've
seen Bearophile suggest it quite a few times, and I agree that
it'd be very
useful to have contracts t
On Wednesday, 30 April 2014 at 16:55:06 UTC, Andrei Alexandrescu
wrote:
Walter and I also discussed "static unittest" a while ago -
yes, another use of static :o).
A static unittest would be evaluated only during compilation,
and would prove things that fall in the realm of static
checking bu
On Wednesday, 30 April 2014 at 16:55:06 UTC, Andrei Alexandrescu
wrote:
Walter and I also discussed "static unittest" a while ago -
yes, another use of static :o).
A static unittest would be evaluated only during compilation,
and would prove things that fall in the realm of static
checking bu
On Tuesday, 29 April 2014 at 11:52:04 UTC, bearophile wrote:
Instead of the ugly and bug-prone mess of "read(fd, &size,
sizeof(int));" I have used something nicer. "tryRead!uint"
tries to read an uint, and returns a Nullable!uint. The "Maybe"
is a function currently missing in Phobos
(https://
On Tuesday, 29 April 2014 at 10:51:26 UTC, Ola Fosheim Grøstad
wrote:
For closures for arrays and dicts.
I don't understand
I used the wrong term, I meant list comprehensions. The most
important feature in Python for me. I find it very powerful in
combination with tuples, lists and dicts.
On Thursday, 24 April 2014 at 16:23:22 UTC, Andrei Alexandrescu
wrote:
Guess we could link from dlang.org to some. -- Andrei
It would be neat to have some of the shorter Rosetta Code
examples on rotation... Do they allow the examples to be
displayed outside of RC?
On Thursday, 24 April 2014 at 16:23:22 UTC, Andrei Alexandrescu
wrote:
Guess we could link from dlang.org to some. -- Andrei
It would be neat to have some of the shorter Rosetta Code
examples on rotation... Do they allow the examples to be
displayed outside of RC?
On Tuesday, 22 April 2014 at 21:35:31 UTC, Meta wrote:
Does this work if test is in a different module from main?
struct test
{
private int opBinary(string op: "*")(test other) { return 3; }
public alias opMul = opBinary!"*";
}
void main()
{
On Tuesday, 22 April 2014 at 15:50:21 UTC, Daniel Murphy wrote:
"Andrej Mitrovic" wrote in message
news:ifghzjafvfqrqkhlp...@forum.dlang.org...
Old-style operator overloads (such as opCom, opAnd, etc) have
largely been superseded by new-style templated operator
overloads (opUnary, opBinary,
On Monday, 21 April 2014 at 16:35:23 UTC, Artur Skawina via
Digitalmars-d wrote:
On 04/21/14 14:45, Steven Schveighoffer via Digitalmars-d wrote:
Reasons off the top of my head not to make them module
functions:
[...]
Functions, unlike methods, do not work with rvalues.
Ie
struct S {
On Wednesday, 16 April 2014 at 03:58:08 UTC, bearophile wrote:
Meta:
//TypeTuple or just bare list?
alias everything = TypeTuple!(@safe, nothrow, pure,
@gc(false));
or
alias everything(Attrs...) = Attrs;
I think that the Microsoft language with effect algebra
(Bearophile has mentioned it
On Tuesday, 15 April 2014 at 21:42:51 UTC, Walter Bright wrote:
On 4/15/2014 2:41 PM, Brad Anderson wrote:
Yes, please. Too few of the attributes have inverse attributes.
That's a subject for another DIP.
This would go fairly well with Andrei's idea of passing true or
false to an attribute
On Saturday, 12 April 2014 at 22:40:32 UTC, H. S. Teoh wrote:
Now if we can only iron out the last 5% of D's wrinkles, it
would be a
HUGE relief from C/C++ nastiness. (Unfortunately, Pareto's
principle
dictates that this last 5% is gonna take us 95% of the time.
:-P)
T
You mean the first
On Saturday, 12 April 2014 at 13:33:07 UTC, Jonathan M Davis
wrote:
On further reflection, I think that having enum and final enum
would make
sense as long as enum were changed so that it introduced an
alias rather than
a new type. A new type just doesn't make sense if you're not
listing all th
On Friday, 11 April 2014 at 16:42:30 UTC, Walter Bright wrote:
On 4/11/2014 5:18 AM, Steven Schveighoffer wrote:
If, after the last year of hacking, and the heartbleed bug,
people are not using
password tracker/generators, you haven't learned anything :)
But those pw managers are a single poi
On Friday, 11 April 2014 at 15:43:16 UTC, Dicebot wrote:
On Friday, 11 April 2014 at 15:15:21 UTC, Meta wrote:
Hasn't there been a proposal before to allow
@system/@trusted/@safe blocks, allowing it to be a bit more
granular than at the function level? Maybe:
@trusted
{
arr.ptr[
On Friday, 11 April 2014 at 14:06:33 UTC, Daniel Murphy wrote:
Trying to prevent developer stupidity is a lost cause.
Bounds checks are on by default. They are even on when you ask
for 'fast-over-safe' aka -release. They get turned off when
you explicitly ask for it.
But there is a cost, e
I swear by LastPass as well. It's a great tool.
On Thursday, 10 April 2014 at 04:47:31 UTC, Walter Bright wrote:
It makes perfect sense if you think of an enum as an integral
type, some values of which have names, as in the "Color"
example I posted earlier.
I do not wish to think of enums in this way. Your use-case is
better solved with Ty
On Thursday, 10 April 2014 at 02:20:10 UTC, deadalnix wrote:
Indeed, it is an unknown enum value. The whole problem come
from the fact that we try to have one thing do two things (ie a
set of value and a set of orable values).
Fairly certain the second use case can be implemented as a
library
On Wednesday, 9 April 2014 at 21:18:38 UTC, bearophile wrote:
I have also counted about 38 unsorted casts that don't easily
fit in the precedent categories. They are so varied that it's
not easy to find ways to avoid them.
In my post I have not shown examples of the casts for the this
"unsort
On Wednesday, 9 April 2014 at 18:18:57 UTC, Meta wrote:
On Wednesday, 9 April 2014 at 18:05:15 UTC, Andrei Alexandrescu
wrote:
That was for C++, and a function vs. a cast didn't improve the
experience much. -- Andrei
The difference being that a function is safe whereas a cast is
not.
On Wednesday, 9 April 2014 at 18:05:15 UTC, Andrei Alexandrescu
wrote:
That was for C++, and a function vs. a cast didn't improve the
experience much. -- Andrei
The difference being that a function is safe whereas a cast is
not.
On Wednesday, 9 April 2014 at 16:47:18 UTC, Andrei Alexandrescu
wrote:
Very true. In hhvm, we tried an enum class to avoid bugs with
using wrong indices in a couple of specific arrays. There were
so many darned casts around, we had to revert the change.
There are many ways to get around this,
On Tuesday, 8 April 2014 at 19:09:55 UTC, Andrei Alexandrescu
wrote:
1. Is the current design damaging enough (= allows enough
wrong/buggy code to pass through) to warrant a breaking
tightening?
Enums in D *should* be tightened to be at least type-safe, but I
don't think it's a large issue.
On Monday, 7 April 2014 at 19:47:24 UTC, Frustrated wrote:
it would be relatively easy.
void myfunc(name = int x) { }
instead of
void myfunc(int x) { }
then
myfunc(name = 4);
or one could simply use the variable name
void myfunc(int x) { }
myfunc(x = 3);
Of course assignments may not be
On Friday, 4 April 2014 at 02:10:15 UTC, dnewbie wrote:
Please vote now!
http://www.easypolls.net/poll.html?p=533e10e4e4b0edddf89898c5
See also results from previous years:
- http://d.darktech.org/2012.png
- http://d.darktech.org/2013.png
I'd been aware of D since around 2008, but didn't actua
On Thursday, 3 April 2014 at 16:34:28 UTC, Vladimir Panteleev
wrote:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:
You can view the rought draft here.
https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing
Could you please use canonical links
On Wednesday, 2 April 2014 at 20:53:53 UTC, Joseph Rushton
Wakeling wrote:
Honestly think that you should go with the solution that will
make it easiest to write and share the results. The point of a
newsletter like this is to communicate! You could do much
worse than a Wordpress blog -- simp
On Wednesday, 2 April 2014 at 14:31:49 UTC, Wyatt wrote:
This is a good base. In general, I would suggest not shying
away from subheadings. It gives you more opportunities to
catch the eye and tends to allow readers to see the parts that
interest them more easily. Conversely, making phrases
On Wednesday, 2 April 2014 at 11:34:34 UTC, Dicebot wrote:
Awesome stuff there!
I do want to propose one fundamental change though - change
grouping / ordering to be based on potential importance to the
casual end user and not by information origin. For example, I
am pretty sure that merged -
On Wednesday, 2 April 2014 at 01:05:31 UTC, Andrei Alexandrescu
wrote:
This is awesome. I intentionally have little to say on the
content proper because of the considerations that follow.
1. As one who led similar efforts (magazine columns etc) I
concur that this is a marathon more than a jog.
On Wednesday, 2 April 2014 at 00:26:58 UTC, bearophile wrote:
Looks quite nice. But I suggest to avoid this wizbang style of
writing, and use one more fit for a technical newsletter:
I'm worried about it being too dry, as it's really just
regurgitating information that's already freely availab
On Wednesday, 2 April 2014 at 00:25:08 UTC, Mike wrote:
I think the email will work well, but it might also be nice to
have a public document that contributors could edit directly.
It might save you some cutting/pasting/word-smithing time.
Maybe then all you would need to do is perform a fina
On Tuesday, 1 April 2014 at 23:35:55 UTC, Brad Anderson wrote:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:
https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing
The link requires access to be granted to view (it lets you
request access
On Tuesday, 1 April 2014 at 23:33:48 UTC, Brad Anderson wrote:
On Tuesday, 1 April 2014 at 23:30:02 UTC, Meta wrote:
On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:
Looks good.
http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d
Vote up, everyone
On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:
Looks good.
http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d
Vote up, everyone!
Please remove this, as I explicitly asked it not to be posted yet.
Thanks to an unexpected free afternoon due to a brutal spring
blizzard, and large amount of caffeine, I've come up with an
initial draft of a D newsletter. It's tentatively named "What's
New in D", and it's purpose is to aggregate the important
community news in one place, as well as to give D
On Monday, 31 March 2014 at 23:57:09 UTC, srean wrote:
On Monday, 31 March 2014 at 15:24:03 UTC, Meta wrote:
On Monday, 31 March 2014 at 15:22:23 UTC, Meta wrote:
What's the title on Hackernews? I can't seem to find it.
Eh, nevermind, found it.
Hackernews really needs a searc
On Monday, 31 March 2014 at 14:00:28 UTC, Atila Neves wrote:
http://atilanevesoncode.wordpress.com/2014/03/31/increasing-performance-with-static-polymorphism-and-other-neat-tricks/
http://www.reddit.com/r/programming/comments/21tszv/increasing_performance_with_static_polymorphism/
On hacker new
On Monday, 31 March 2014 at 15:22:23 UTC, Meta wrote:
What's the title on Hackernews? I can't seem to find it.
Eh, nevermind, found it. Hackernews really needs a search
function.
On Saturday, 29 March 2014 at 00:58:46 UTC, Meta wrote:
I'm confused now. What exactly was it that you were saying
didn't make sense?
Ah, I see now. When I said "it's a bit unintuitive as to what
works and what doesn't", I was talking about how unless you know
e
On Friday, 28 March 2014 at 22:39:24 UTC, Timon Gehr wrote:
You mean because the literal is accepted as an alias argument?
Alias template arguments are not actually the same thing as
alias declarations. (Eg. the latter can accept built-in types
like 'int', while the former will not, but otherwi
It is a bug. It might be correct in monarch's world but it is
not logical. I think monarch is just trying to justify the way
D does it, regardless if D is D is wrong or not.
You mean how *every* C-derived language does it?
On Thursday, 27 March 2014 at 22:33:50 UTC, Timon Gehr wrote:
It doesn't make sense at all. It is an arbitrary limitation.
The rule is simple though: One can only alias things that
syntactically look like they might be types. This is why the
following triviality is way more useful than it shoul
On Thursday, 27 March 2014 at 17:30:58 UTC, Simen Kjærås wrote:
Ah, true. Call it an enhancement request, then. Wanting to
alias a function literal like that is so common the language
should support it.
--
Simen
It's a bit unintuitive as to what works and what doesn't
(although it makes s
On Thursday, 27 March 2014 at 16:42:31 UTC, Simen Kjærås wrote:
That could very well be argued to be a bug, though.
--
Simen
What is the bug? Alias aliases symbols. A function literal is not
a symbol, but a template instantiation is. Therefore, wrapping a
function literal in a template ins
On Thursday, 27 March 2014 at 17:21:14 UTC, Meta wrote:
On Thursday, 27 March 2014 at 16:42:31 UTC, Simen Kjærås wrote:
That could very well be argued to be a bug, though.
--
Simen
What is the bug? Alias aliases symbols. A function literal is
not a symbol, but a template instantiation is
On Thursday, 27 March 2014 at 16:33:53 UTC, monarch_dodra wrote:
Also yes, but the general feeling around here, is that "string
functions" are a thing of the past, and should be replaced by
"real" lambda functions.
As such, even if "naryFun" works, it promotes the use of
something that is unp
On Thursday, 27 March 2014 at 13:23:27 UTC, monarch_dodra wrote:
"fold" (from what I understood) is what you call "foldl". It
was discussed to not introduce "foldr", as it's just
"fold!(binaryReverseArgs!Fun)(range.retro);".
Rolls right off the tongue. We seriously need a better alias for
bin
On Thursday, 27 March 2014 at 09:44:19 UTC, Dicebot wrote:
Poke me if you need some help with gathering actual topics to
pay attention to - I am doing full parsing of NG / GitHub DMD
anyway so it won't cost me any more time on top.
Sure, where can I reach you at? I could've sworn that there's
On Wednesday, 26 March 2014 at 05:24:42 UTC, Andrei Alexandrescu
wrote:
http://cmr.github.io/blog/2014/03/24/this-week-in-rust/
They mention what happened, who's contributing, and such. Would
love to see somebody in our community initiating something
similar.
Andrei
This is somewhat timel
On Tuesday, 25 March 2014 at 17:37:34 UTC, Frustrated wrote:
Is it possible for the compiler to warn/mark functions,
templates, and types that use the GC?
e.g., I have a mixin template that has a static associative
array. At some point I would like to remove the GC dependence
but the only wa
On Tuesday, 25 March 2014 at 17:33:20 UTC, Andrei Alexandrescu
wrote:
After the recent discussions regarding the comma operator, and
after inspecting the patterns of code affected by it, Walter
and I would back up the following change to the D language:
1. The comma operator stays with its cur
On Tuesday, 25 March 2014 at 17:22:45 UTC, monarch_dodra wrote:
I'm working on something called "fold". It is designed as
nothing more than a replacement for "reduce", but where the
seed comes *second* in terms of arguments. It allows this:
someLongUFCSChain().reduce(intoThis);
It might not l
On Monday, 24 March 2014 at 12:44:22 UTC, bearophile wrote:
w0rp:
I am a regular Python user, and I advise against using this
syntax for tuples. I have been bitten many times by something
which I thought was a tuple becoming an expression and
something I thought was a simple expression becomi
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu
wrote:
One concession we could make would be to disallow using the
result of the operator. That might actually catch all bugs
discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRe
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu
wrote:
Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
Andrei
You mentioned on the Github PR that this broke some Phobos (and
Druntime?) code. What was the extent of the breakage? If it's
small, I'd say give it a
On Sunday, 23 March 2014 at 10:01:32 UTC, Messenger wrote:
On Saturday, 22 March 2014 at 16:23:31 UTC, Paulo Pinto wrote:
Dub was a very good decision.
The logo is... unfortunate. As in, OGC-level unfortunate.
https://www.google.com/search?safe=off&site=&tbm=isch&source=hp&q=OGC
Cannot unse
On Friday, 21 March 2014 at 19:19:06 UTC, Walter Bright wrote:
Here's a litmus test you can use for purity. Consider:
int foo() pure;
{
auto a = foo();
}
Now, since 'a' is never used, we can delete the assignment, and
since foo is pure, we can delete foo():
{
}
I
On Wednesday, 19 March 2014 at 22:30:55 UTC, Peter Alexander
wrote:
On Sunday, 16 March 2014 at 16:58:36 UTC, Andrei Alexandrescu
wrote:
A classic idiom for reading lines and keeping them is
f.byLine.map!(x => x.idup) to get strings instead of the
buffer etc.
f.readLines
What about a simple
On Wednesday, 19 March 2014 at 17:43:03 UTC, Andrei Alexandrescu
wrote:
Same here. I do remember that wasn't the peak of it. That
happened when I tried to explain something as a "cultural
difference". Probably it was taken as "cultural
inferiority/superiority".
Andrei
More like feigned idio
On Wednesday, 19 March 2014 at 16:46:41 UTC, Dicebot wrote:
No, I don't mean iterate with predicate. I mean /dev/null thing.
My point is that `range.each!predicate` is much better replaced
with `range.tap!predicate.consume`. It keeps general rule of
range stuff being lazy and only single excep
On Wednesday, 19 March 2014 at 15:06:40 UTC, Andrei Alexandrescu
wrote:
Pros and cons are already being discussed. Destroy!
https://github.com/D-Programming-Language/phobos/pull/2024
Andrei
Very similar to one of the additions I proposed awhile ago. The
only difference is that my each() did
On Wednesday, 19 March 2014 at 01:56:35 UTC, Rikki Cattermole
wrote:
Is an enum not appropriate? Because it can be used to push
constants and available at ctfe.
enum int[int] aa = [1: 2, 3: 4];
pragma(msg, aa);
This will create a new associative array at runtime wherever aa
is used, rather t
On Wednesday, 19 March 2014 at 01:52:07 UTC, bearophile wrote:
nor to contain the most optimized algorithms around.
This D1 code adapted from C code is much more efficient (and in
D2 with ranges and TypeTuple-foreach it could become more
efficient and much shorter), but I think something like
On Monday, 17 March 2014 at 22:29:26 UTC, Meta wrote:
On Monday, 17 March 2014 at 21:26:42 UTC, monarch_dodra wrote:
On Monday, 17 March 2014 at 21:08:12 UTC, Joseph Rushton
Wakeling wrote:
On 16/03/14 23:37, monarch_dodra wrote:
Thoughts? Suggestions for names?
sync ... ? (or synch
On Monday, 17 March 2014 at 21:26:42 UTC, monarch_dodra wrote:
On Monday, 17 March 2014 at 21:08:12 UTC, Joseph Rushton
Wakeling wrote:
On 16/03/14 23:37, monarch_dodra wrote:
Thoughts? Suggestions for names?
sync ... ? (or synch)
"sync" actually went through my head. In the the context of
On Monday, 17 March 2014 at 07:56:20 UTC, Mason McGill wrote:
I just wrote a DIP aimed at improving slicing and range
construction syntax while maintaining backwards compatibility,
and I'd like to hear your opinions!
http://wiki.dlang.org/DIP58
It can be thought of as an elaboration on the app
On Sunday, 16 March 2014 at 17:49:56 UTC, bearophile wrote:
Andrei Alexandrescu:
A classic idiom for reading lines and keeping them is
f.byLine.map!(x => x.idup) to get strings instead of the
buffer etc.
This is essentially this issue, I will reopen it if you want:
https://d.puremagic.com/is
On Thursday, 13 March 2014 at 03:05:07 UTC, Vladimir Panteleev
wrote:
So are you saying that the users who participate on the forum
are not representative of the entire D user base? I.e. the % of
users who wouldn't mind breaking changes is higher on the forum?
The 1% rules suggests this forum
On Wednesday, 12 March 2014 at 16:44:09 UTC, Andrei Alexandrescu
wrote:
On 3/12/14, 4:08 AM, Iain Buclaw wrote:
I came across this for EMACS.
http://emacs.sexy/
Which got me thinking, now we have a new .sexy domain
available for the
public, who wants to go out and buy dlang.sexy (and talk abo
On Tuesday, 11 March 2014 at 00:02:13 UTC, bearophile wrote:
Walter Bright:
In the last couple days, we also wound up annoying a valuable
client with some minor breakage with std.json, reiterating how
important it is to not break code if we can at all avoid it..
There are still some breaking
On Thursday, 6 March 2014 at 21:26:45 UTC, Walter Bright wrote:
A major goal for D in the short term is to reduce reliance in
Phobos on the GC. I was looking at std.string last night, and I
noticed a couple things:
1. The inputs are constrained to being strings. This is overly
restrictive, th
On Tuesday, 4 March 2014 at 23:35:25 UTC, Jesse Phillips wrote:
On Tuesday, 4 March 2014 at 22:42:34 UTC, Meta wrote:
but I doubt they would pay much attention to an anonymous D
fan.
Probably not any less than the original submitter.
I can't say I like the moderation choices /r/progra
On Tuesday, 4 March 2014 at 21:12:00 UTC, Walter Bright wrote:
That one got marked as 'dead' too.
Hackernews is mostly a Go site. I'd be very surprised if they
deleted a Go conference announcement.
Something seems weird here. It might be worth emailing the
maintainers and asking why it keeps
On Monday, 3 March 2014 at 16:11:48 UTC, Steve Teale wrote:
I did not get any takers in D Learn, so I'll try again here.
Mixin templates are supposed to be instantiated in the scope
where they were invoked. I have tried one that I want to invoke
in the body of a constructor, but it fails when
On Saturday, 1 March 2014 at 23:51:32 UTC, Martin Nowak wrote:
Just another wishlist thread?
Clearly for a roadmap you have to match demand with possible
supply.
If you want to implement something or you found someone to do
it for you put it on the Agenda (http://wiki.dlang.org/Agenda).
Does
On Tuesday, 25 February 2014 at 20:48:08 UTC, Jacob Carlborg
wrote:
On 2014-02-21 13:12, Dicebot wrote:
http://wiki.dlang.org/Review/std.lexer
This is follow-up by Brian to his earlier proposal
(http://wiki.dlang.org/Review/std.d.lexer). This time proposed
module
focuses instead on generic lex
On Tuesday, 25 February 2014 at 00:28:26 UTC, Adam Wilson wrote:
[SNIP]
You're throwing what I said way out of proportion. I was replying
to the statement:
"No criticism should stop this module being accepted, as we do not
have any other lexer in the runtime anyway. Therefore I suggest
we ac
On Monday, 24 February 2014 at 23:07:07 UTC, Adam Wilson wrote:
Well, we keep voting down replacement candidates, which
incidentally, is exactly what happened with the std.signals
replacement, so I view this as an orthogonal issue to whether
or not it should be included after passing a review.
On Monday, 24 February 2014 at 22:14:34 UTC, Dejan Lekic wrote:
No criticism should stop this module being accepted, as we do
not have any other lexer in the runtime anyway. Therefore I
suggest we accept std.lexer until a better solution comes up.
Naturally anyone should be encouraged to provid
On Monday, 24 February 2014 at 01:12:56 UTC, Andrei Alexandrescu
wrote:
This makes inlining dependent on previously-seen code. Would
that make parallel compilation more difficult?
I've always thought the obvious/simple way would be an
attribute such as @forceinline and @noinline that applies t
On Saturday, 22 February 2014 at 03:41:29 UTC, Jesse Phillips
wrote:
On Saturday, 22 February 2014 at 03:03:18 UTC, Meta wrote:
This code works fine:
http://dpaste.dzfl.pl/c0b3a941d917
That is an anonymous class, that is defining and instantiating
the class, which isn't what the scala
On Saturday, 22 February 2014 at 02:52:37 UTC, Jesse Phillips
wrote:
On Saturday, 22 February 2014 at 01:39:28 UTC, deadalnix wrote:
On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright
wrote:
On 2/21/2014 5:27 PM, deadalnix wrote:
That makes me sad that D has Java's object model rather
701 - 800 of 993 matches
Mail list logo
