On Tuesday, 10 June 2014 at 18:12:37 UTC, Mattcoder wrote:
Finally my question is: Wouldn't be relevant and a good
advertisement try to port a code like this to D and compare the
times? Because one of the strenghts of D it's the fast
compilation time, right?
Assuming you have enough RAM
On Thursday, 12 June 2014 at 09:48:30 UTC, Kagamin wrote:
Why private members can't have internal linkage?
tl; dr: because private provides zero guarantees that symbol
won't be referenced in ABI context. It only controls direct
language level access.
It can possibly be done with analysis
On Thursday, 12 June 2014 at 14:23:59 UTC, Jacob Carlborg wrote:
On 12/06/14 11:48, Kagamin wrote:
Why private members can't have internal linkage?
It's currently possible to access private symbols through
pointers.
And aliases with different qualifiers. And via return values. And
with
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d
wrote:
I often find myself wanting to write this:
foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
You can do this:
for(;;) {}
On Friday, 13 June 2014 at 12:01:00 UTC, Tom Browder via
Digitalmars-d wrote:
On Wed, Jun 4, 2014 at 4:12 PM, Brian Schott via Digitalmars-d
digitalmars-d@puremagic.com wrote:
I've been looking at ways to optimize the D lexer's operation
using SIMD
Brian, i just found the lexer code repo (and
On Friday, 13 June 2014 at 14:59:55 UTC, Dejan Lekic wrote:
Please no. See: javax
Spelling out 'experimental' is probably the best, for all
those reasons
already stated.
What's wrong with javax?
The fact that it started as same experimental package but stuff
there never got moved to
On Friday, 13 June 2014 at 15:48:37 UTC, Timon Gehr wrote:
On 06/13/2014 01:55 PM, Dicebot wrote:
Over 50 comments about minor syntax issue ...
Including yours.
That was my first comment in this thread :O
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it does is disallow instantiating the type without
specifying an initializer (e.g. a struct literal, a value
returned from a factory function, or `static opCall()`).
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
The idea of disabled this() is to prevent default
On Saturday, 14 June 2014 at 16:41:46 UTC, monarch_dodra wrote:
.init should simply mean the default bit state of the
object. Let's not make it into anything more complicated than
that.
I guess this is the root of disagreement. There is no place in
documentation that says that T.init is in
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand what people think of D. I
can confirm this sentiment is fairly
Big problem with GitHub issues is how simplistic those are. All
categorization is done by labels with no internal
differentiation, advanced search queries are not possible. Also
bugzilla is self-hosted solution we have full control about and
with GitHub you can only rely on what external API
On Sunday, 15 June 2014 at 15:31:40 UTC, Brian Rogoff wrote:
On Sunday, 15 June 2014 at 11:28:12 UTC, Peter Alexander wrote:
http://c0de517e.blogspot.ca/2014/06/where-is-my-c-replacement.html?m=1
The arguments against D are pretty weak if I'm honest, but I
think it's important we understand
On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote:
On Sunday, 15 June 2014 at 11:45:30 UTC, Dicebot wrote:
I like how he says that productivity is important and mentions
fear of meta-programming in the same article ;)
That's true, but meta programming is just a tool. Would be
On Sunday, 15 June 2014 at 16:21:03 UTC, bearophile wrote:
Andrew Edwards:
Already proven a valuable resource, GitHub offers the tools
necessary to resolve this problem. The issues feature (not
currently activated for any D-Programming-Language repo)
allows us to set milestones (with due
http://wiki.dlang.org/DIP63
This is solution for a problem I am currently having with
implementing http://wiki.dlang.org/DIP54 (afair it was also
mentioned by Timon Gehr during old discussion of that DIP)
New proposed semantics ( to catch your attention and get to read
the link ;) ):
On Sunday, 15 June 2014 at 17:40:58 UTC, Andrew Edwards wrote:
True, we do not have access to anything but the external API,
however I don't see that as a limiting factor. When I conduct a
search in DITS, I effectively search through labels. Of course
those labels present themselves as data
On Sunday, 15 June 2014 at 21:11:38 UTC, Paolo Invernizzi wrote:
On Sunday, 15 June 2014 at 16:06:08 UTC, Dicebot wrote:
On Sunday, 15 June 2014 at 13:50:10 UTC, Peter Alexander wrote:
Had some good time of my own debugging Boost::Spirit2 _
That's simply an impossible task! ;-P
If spending
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via Digitalmars-d
wrote:
What say you to that, Walter?
Apple have committed to pervasive ARC, which you consistently
argue is
not feasible...
Have I missed something, or is this a demonstration that it is
actually practical?
Good luck writing
On Monday, 16 June 2014 at 17:12:27 UTC, Benjamin Thaut wrote:
Am 16.06.2014 18:23, schrieb Namespace:
On Monday, 16 June 2014 at 16:19:55 UTC, Dicebot wrote:
On Monday, 16 June 2014 at 15:16:44 UTC, Manu via
Digitalmars-d wrote:
What say you to that, Walter?
Apple have committed to
On Monday, 16 June 2014 at 08:56:24 UTC, Marc Schütz wrote:
I guess there's no way around it, but it seems inconsistent
that the operators are defined as templated aliases instead of
functions as anywhere else. Could you add a paragraph to the
DIP which points this out and give a short
On Monday, 16 June 2014 at 12:37:55 UTC, matovitch wrote:
And why these operators only ?
tl; dr: because I am limiting proposal to what I am actually able
and willing to implement :)
On Monday, 16 June 2014 at 18:50:10 UTC, Walter Bright wrote:
http://www.reddit.com/r/programming/comments/289dtq/where_is_my_c_replacement/
http://forum.dlang.org/thread/mmvsadwyejjfmqnrc...@forum.dlang.org
On Monday, 16 June 2014 at 22:07:04 UTC, Kapps wrote:
On Monday, 16 June 2014 at 22:01:40 UTC, Idan Arye wrote:
D is still unstable. Any time now non-null-by-default can get
in and break tons of libraries and user code.
That's not going to happen.
Yeah don't confuse actively discussed
On Tuesday, 17 June 2014 at 00:26:56 UTC, deadalnix wrote:
I have nothing against it BUT...
The fact that you need this is a proof that
TemplateArgumentList/TemplateArgumentPack have actually use
outside being template argument list and/or pack.
Your just defeated you whole Q/A on DIP54...
On Tuesday, 17 June 2014 at 00:36:43 UTC, deadalnix wrote:
To be more constructive, naming something by its use will
fatally look very weird and confusing when other uses are
found. And here we see that it is not even implemented but
already have other uses. Can we please avoid that pitfall ?
On Tuesday, 17 June 2014 at 04:24:54 UTC, c0de517e wrote:
Hi everybody. I'm Angelo Pesce, the author of the post on
c0de517e.
...
Thanks for coming here and clarifying your point of view despite
our zealous bashing :) Welcome!
On Tuesday, 17 June 2014 at 04:03:23 UTC, Mike Parker wrote:
On 6/17/2014 12:16 PM, Caligo via Digitalmars-d wrote:
My rant wasn't about his lack of fluency in the English
language. You
only learn once what a sentence is, and the concept translates
over to
most other natural languages. The
On Tuesday, 17 June 2014 at 10:25:39 UTC, dennis luehring wrote:
Am 17.06.2014 11:30, schrieb Walter Bright:
And how would you syntax-highlight a string mixin that's
assembled from
arbitrary string fragments?
You wouldn't need to, since the text editor sees only normal D
code.
the text
On Tuesday, 17 June 2014 at 13:13:00 UTC, Artur Skawina via
Digitalmars-d wrote:
artur (who implemented both features last weekend; it started
out as a
fun let's-see-how-D-would-look-if-it-had-this-project, but
after making
them work and then converting a few small programs, almost
immediately
On Tuesday, 17 June 2014 at 13:36:48 UTC, John Colvin wrote:
also, foreach that works outside of function scope would be
awesome:
mixin template A(TL ...)
{
foreach(i, T; TL)
{
mixin(T v ~ i.to!string);
}
}
It is not also, it is primary use case of
On Tuesday, 17 June 2014 at 13:23:48 UTC, Andrew Edwards wrote:
The argument I'm hearing from the majority (at least those who
choose to respond) is too much work for minimal gain.
I stand by the point that gain is not minimal, it is actually
negative. Loss of power search tools is huge
On Tuesday, 17 June 2014 at 14:00:44 UTC, John Colvin wrote:
I though the primary use of static foreach was to force the
compiler to attempt compile-time iteration even for
non-TemplateArgList arguments like arrays known at compile-time
If static foreach acts as code generator there is no
Heh: http://forum.dlang.org/post/lnhtiq$qqn$1...@digitalmars.com
On Tuesday, 17 June 2014 at 20:26:11 UTC, deadalnix wrote:
No SFINAE please. That is an idiotic C++ idiom. use template
constraints if you want to disable this template for some
parameter sets. static assert is to statically assert. In this
case it fails. As it should !
As far as I understand
On Wednesday, 18 June 2014 at 07:05:13 UTC, deadalnix wrote:
On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright wrote:
On 6/17/2014 11:50 PM, deadalnix wrote:
and the fact that @safe is defined backward (ie by listing
what is not allowed and
adding to the list when new holes are
On Wednesday, 18 June 2014 at 11:09:14 UTC, Artur Skawina via
Digitalmars-d wrote:
The number of potential contributors is
already low enough, and the fuzzy licensing situation drives
away the
most valuable ones (since those will often be the ones which
treat the
legal aspects seriously and
On actual topic.
Do I think it is practical approach and has benefits over
existing situation? Definitely yes.
Do I think it is the right design with a more idealized
infrastructure? No. As Dmitry has mentioned it has huge flaw of
not being able to use template alias and type arguments,
On Wednesday, 18 June 2014 at 07:58:57 UTC, c0de517e wrote:
People think that implementing interfaces is for some reason
inherently slower than templates, the same they believe
function pointers are slower than functors. It's FALSE. The
ONLY reason why templates and functors can be faster is
On Wednesday, 18 June 2014 at 16:19:25 UTC, c0de517e wrote:
But as I wrote I doubt that people will think at a point that
yes, now D is 100% a better version of C++/Java/younameit,
let's switch. I don't think it's how things go, I think
successful languages find one thing a community really
Also I think all this discussion about template and generics
totally misses the point about meta-programming. It is not about
just code generation or replacing few type declarations, main
thing is compile-time reflection. The fact we use templates is
just a mere implementation details. What
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by accepting
what it is and act accordingly.
Being ashamed of it instead of glorifying such attitude is one
way to motivate
On Wednesday, 18 June 2014 at 19:09:08 UTC, c0de517e wrote:
On Wednesday, 18 June 2014 at 18:18:28 UTC, Dicebot wrote:
On Wednesday, 18 June 2014 at 18:17:03 UTC, deadalnix wrote:
This is, but that's how it works nevertheless. You don't
succeed by arguing what the reality should be, but by
On a related topic:
Feature like this is extremely convenient for unit tests. However
using assertions in unit test blocks does not fit well with any
custom test runner that does not immediately terminate the
application (because AssertionError is an Error).
I'd personally love some way to
+1
I have always wondered why `inout` is limited to const when
problem is almost identical with all other restrictive attributes.
'main` is C main function inside druntime. Your program entry
point is _Dmain. You may also want to try git master built of gdb
with Iain Buclaw patches for enhanced D support - those are
awesome beyond imagination and, among other things, add support
for D symbol (de)mangling :)
On Friday, 20 June 2014 at 20:04:32 UTC, Jacob Carlborg wrote:
On 2014-06-19 19:52, Dicebot wrote:
On a related topic:
Feature like this is extremely convenient for unit tests.
However using
assertions in unit test blocks does not fit well with any
custom test
runner that does not
On Thursday, 19 June 2014 at 11:12:46 UTC, Artur Skawina via
Digitalmars-d wrote:
Wait what? Do you know a single person who decided to not work
on DMD FE because of kind of formally (but not practically)
non-free backend?
Well, do you think I would have said what I did if this issue
didn't
On Saturday, 21 June 2014 at 18:57:25 UTC, Suliman wrote:
and save syntactic sugar for more useful features.
How not implementing this future will help to save syntactic
sugar?
There is a limited amount of non-widespread syntax sugar you can
fit into language without harming its learning
On Saturday, 21 June 2014 at 10:49:57 UTC, Artur Skawina via
Digitalmars-d wrote:
In other words, what is potential danger you need to be
concerned about that makes potential contributions too risky?
One problem I am aware of is redistribution issue which is
common blocker with getting into
On Sunday, 22 June 2014 at 15:01:57 UTC, Artur Skawina via
Digitalmars-d wrote:
On 06/22/14 15:13, Dicebot via Digitalmars-d wrote:
You are passing copyright to DigitalMars for all contributions
anyway, Boost or proprietary.
Not true in general. Or are you saying that Walter requires
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
I agree, but that's what they're called in the compiler source
code, so
it's kinda hard to call them something else.
Most people never look in compiler source code so lets pretend it
does not exist ;)
On Friday, 27 June 2014 at 19:11:45 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, Jun 27, 2014 at 06:32:34PM +, Dicebot via
Digitalmars-d wrote:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
I agree, but that's what they're called in the compiler
source
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
I like DIP54 and I think the work on fixing tuples is awesome,
but I have 1 nit-picky question: why is it called
TemplateArgumentList when it's not always used as template
arguments?
void func(string, string) { }
On Saturday, 28 June 2014 at 19:39:35 UTC, deadalnix wrote:
You keep repeating that, but people keep being confused. It is
time to admit defeat.
I don't think any name is possible which don't keep someone
confused - as long as this entity behaves as it does.
'StaticList' is what you may
On Saturday, 28 June 2014 at 16:11:15 UTC, Mason McGill wrote:
Understood. I was just expressing my initial impression: that
it seemed strange that a symbol declared as a
`TemplateArgumentList` was neither passed nor received as
template arguments.
My hope is that having such surprising name
On Saturday, 28 June 2014 at 14:21:03 UTC, Nordlöw wrote:
I doubt bounties are effective as a motivation for this kind
of thing.
If so couldn't you make your code public?
Don does not have any code that actually fixes that issue. He as
done a lot of job on CTFE refactoring and unification
On Saturday, 28 June 2014 at 21:25:31 UTC, H. S. Teoh via
Digitalmars-d wrote:
We've had this discussion before (and not just once), that
tuple is a
misnomer, yada yada yada, but until somebody files a PR to
change this,
things are just going to continue to remain the same. So I'd
say,
On Sunday, 29 June 2014 at 16:03:07 UTC, Mason McGill wrote:
I understand, but I was talking about `var` being referred to as
a `TemplateArgumentList` when it's not used as such. It's used
as
an `ArgumentList`, just not a `TemplateArgumentList`.
Why do you expect template argument list to be
On Sunday, 29 June 2014 at 20:44:06 UTC, Tofu Ninja wrote:
On Sunday, 29 June 2014 at 16:09:15 UTC, Dicebot wrote:
On Sunday, 29 June 2014 at 16:03:07 UTC, Mason McGill wrote:
I understand, but I was talking about `var` being referred to
as
a `TemplateArgumentList` when it's not used as such.
On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:
On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:
My opinion is that the redesign preserves the spirit of the
current logo while fitting in well with the flatter look. I
think someone who sees the one logo will
On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:
I just finished translating all of the pages I have worked on
so far from diet templates to Markdown files. Now there is only
one diet layout loaded, and the rest is all Markdown files.
This has dramatically reduced the amount of memory
We don't have any recognizable branding worth fighting for. I
can't even remember how current D logo looks like without
checking the website, it is just some image in the corner of the
page. Branding is something bigger than that.
On Wednesday, 2 July 2014 at 11:48:18 UTC, Shammah Chancellor
wrote:
I don't see a huge difference either. I didn't realize
Nullable was already around. The main thing is that is
valuable is that Nullable/Option extended to reference types,
and then disabling the usual null assignment to
On Wednesday, 2 July 2014 at 17:34:46 UTC, Gary Willoughby wrote:
On Wednesday, 2 July 2014 at 11:02:58 UTC, Dicebot wrote:
We don't have any recognizable branding worth fighting for. I
can't even remember how current D logo looks like without
checking the website, it is just some image in the
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and replaced
with something actually useful.
On Thursday, 3 July 2014 at 11:35:36 UTC, w0rp wrote:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.
:( it was so much better with this ugly widget gone and
replaced with something
On Friday, 4 July 2014 at 20:25:24 UTC, Chris Cain wrote:
On Friday, 4 July 2014 at 19:46:40 UTC, Remo wrote:
Who want to use C-style memory management today ?
How about C++ style memory management, is this easy to this in
D2
now ?
The big problem with that is C++ style memory management
On Friday, 4 July 2014 at 21:15:00 UTC, Chris Cain wrote:
On Friday, 4 July 2014 at 21:09:05 UTC, Remo wrote:
By C++ style memory management I do not mean naked
new/delete or malloc/free.
What I mean is RAII, smart pointers and destructor's.
What is the proper replacement for std::unique_ptr
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
has anyone ever tied a real webservice to vibe.d?
Yes and see no problems with it. Looks like author has very
specific expectations of webservice concept and can't do a
thing with 100%
On Wednesday, 9 July 2014 at 09:47:21 UTC, Dicebot wrote:
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu
wrote:
has anyone ever tied a real webservice to vibe.d?
Yes and see no problems with it. Looks like author has very
specific expectations of webservice concept and can't do
On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote:
Vibe.d is more like a base library for async I/O, networking
and concurrency, a full stack WEB framework should be built on
top of it
Ironically I find pure vibe.d solutions much more clean and easy
to maintain than any enhancements
On Tuesday, 8 July 2014 at 20:40:02 UTC, Walter Bright wrote:
On 7/8/2014 1:39 PM, Walter Bright wrote:
This is all great news, congratulations!
On the gc-sections front, Martin had gotten it to work for DMD
on Linux but then
had to back it out because it failed with the ld.gold linker.
If
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
Hi all,
I am excited to share news about two changes that recently made
their way into the development version of LDC, changes that
might be interesting for many of you Linux users out there.
The first is that LDC now supports
Some minor disagreements:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
2. Unique References
unique_ptrT is another big success for C++. 2.066 has already
made big strides in inferring uniqueness of expressions, but it
doesn't go so far as creating a Unique!T type.
On Wednesday, 9 July 2014 at 02:44:54 UTC, Walter Bright wrote:
On 7/8/2014 6:01 PM, Mike wrote:
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote:
1. Ref Counting
I believe that ARC is a pipe dream for D, as we've discussed
extensively here.
But a ref counted object should work,
On Wednesday, 9 July 2014 at 13:06:06 UTC, Marc Schütz wrote:
std.type.Unique needs to be fleshed out, or a different type
created (`Owned`?).
There is an `Isolated` in vibe.d which is more tuned for usage
with std.concurrency (its vibe.d fork to be specific)
On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:
Completely off-topic, but:
Have you considered making vibe http-backend independent?
So that it could provide a fcgi interface or be included in an
nginx
plugin?
What is the benefit as opposed to using proxy_pass at nginx? fcgi
On Wednesday, 9 July 2014 at 17:01:02 UTC, bearophile wrote:
Dicebot:
I don't know where it comes from but non-nullable reference
type has ZERO value if it is not the default one.
This article talks about switching to NotNull on default in
real (small) Java projects (you have to add a
On Wednesday, 9 July 2014 at 18:09:58 UTC, bearophile wrote:
Dicebot:
Yes and this is exactly what we can't do in D.
I don't understand, if they can do that with Java, why not D?
Bye,
bearophile
Java bytecode reflection makes possible to find all reference
types in an attributed package
On Thursday, 10 July 2014 at 07:50:47 UTC, bearophile wrote:
Walter Bright:
I suggest recognizing in the parser:
( Identifier )
as a special case, in addition to using
Parser::isDeclaration(). Gradually we can turn that special
case into a warning, then deprecation.
It's better to do
On Wednesday, 9 July 2014 at 21:07:26 UTC, Johannes Pfau wrote:
Am Wed, 09 Jul 2014 17:28:42 +
schrieb Dicebot pub...@dicebot.lv:
On Wednesday, 9 July 2014 at 17:05:21 UTC, Johannes Pfau wrote:
Completely off-topic, but:
Have you considered making vibe http-backend independent?
So that
On Wednesday, 9 July 2014 at 19:47:02 UTC, Walter Bright wrote:
Yes, I mean transitive, and understand what that implies.
I am positively shocked :)
I have started work on porting the CDGC to D2, have compilable
version (that was
easy thanks to earlier Sean work) but updating implementation
On Thursday, 10 July 2014 at 03:59:15 UTC, logicchains wrote:
Actually, an important question that should be considered: does
D want actor-style concurrency, like Erlang and Akka, or
CSP-style concurrency, like Rust, Go and Haskell? Or both?
Deciding this would allow efforts to be more
On Thursday, 10 July 2014 at 11:03:20 UTC, logicchains wrote:
Are there any tutorials or blog posts out there demonstrating
how to use this? I think posts along the lines of This is a
CSP/message passing program in Go/Erlang. This is the same
program translated into D; look how concise and
On Thursday, 10 July 2014 at 12:13:03 UTC, bearophile wrote:
Dicebot:
I can't blame Sonke or anyone else for not wanting to waste
his time on pushing more stuff upstream considering how
miserable contribution experience is right now.
This was one of the causes of the creation of Tango and
LDC is officially my favorite D compiler from now 3
..now I only need to finish D2 migration of our code base *caugh*
On Thursday, 10 July 2014 at 14:09:41 UTC, John Colvin wrote:
To be fair to Walter/Andrei, you need to be clear who your
lieutenant is before you can delegate to them.
Who has stepped up to take charge of concurrency in D?
I think it should be other way around - announcing slot with
listed
On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu
wrote:
Then there's stuff I have no expertise in such as
https://github.com/D-Programming-Language/phobos/pull/2307. Not
only I'm not on hook for that, I better not discuss and pull
that and leave it to someone who knows curl
E.g.
https://github.com/D-Programming-Language/phobos/pull/1527 is some
apparently work that's just sitting there abandoned.
Hm, slightly OT: is it considered widely acceptable to take over
such pull requests by reopening rebased one with identical
content? I presume Boost licensing implies
On Thursday, 10 July 2014 at 15:52:45 UTC, Andrei Alexandrescu
wrote:
On 7/10/14, 8:29 AM, Sean Kelly wrote:
Robert's struggle with getting std.logger accepted is the
stuff told to
children around the campfire so they don't venture out into
the dark.
Actually we use his logger at Facebook
On Thursday, 10 July 2014 at 08:07:12 UTC, Jacob Carlborg wrote:
So what's the policy on this? Which tools can be added to
dlang.org? I have a tool, DVM [1], for installing DMD. It's
cross-platform, allows you to install and switch between
multiple versions of DMD. Doesn't require any updates
On Thursday, 10 July 2014 at 18:18:54 UTC, Walter Bright wrote:
You are totally missing the point if you consider this even
comparable
replacement. Reason why non-nullable types are awesome because
you are 100% sure
compiler will force you to handle null cases and if program
compiles it is
On Thursday, 10 July 2014 at 20:57:09 UTC, Marc Schütz wrote:
* Even most methods and library functions can just mark their
parameters as `scope` (or whatever the syntax will be), without
any mentioning of a lifetime or owner.
And the fact that `in` is defined as `const scope` fits nicely
On Thursday, 10 July 2014 at 21:09:00 UTC, Brian Schott wrote:
Does the lieutenant for the wiki know who he is?
If we can promote ourselves to lieutenant, I'm now in charge of
the language spec.
lieutenants are not usually elected but you have my vote anyway ;)
On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:
I've thought of allowing throw new ..., and yours would be in
addition to that, in @nogc functions, but was waiting to see
how this would play out a bit first.
One can replace throwing of Error with printf + abort in @nogc
blocks,
On Friday, 11 July 2014 at 09:29:58 UTC, Dicebot wrote:
On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:
I've thought of allowing throw new ..., and yours would be
in addition to that, in @nogc functions, but was waiting to
see how this would play out a bit first.
One can
Round of a formal review before proceeding to voting. Subject for
Phobos inclusion : http://wiki.dlang.org/Review/std.logger
authored by Robert Schadek.
Code:
https://github.com/D-Programming-Language/phobos/pull/1500
Documentation:
As usual, this review round will last for 2 weeks unless someone
asks for delay.
Please share link to this thread via twitter, reddit, G+ and
whatever else may be used out there.
On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote:
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.
Is this for std.*
201 - 300 of 2167 matches
Mail list logo
