On Saturday, 16 January 2021 at 15:41:38 UTC, solidstate1991
wrote:
On Saturday, 16 January 2021 at 14:18:55 UTC, Tove wrote:
probably you can use
https://dlang.org/spec/traits.html#getOverloads
I don't know how to use it with functions outside of
structs/classes.
void foo() {}
void foo
On Saturday, 16 January 2021 at 14:14:57 UTC, solidstate1991
wrote:
On Saturday, 16 January 2021 at 14:13:29 UTC, solidstate1991
wrote:
Here's the following line, among many others:
return !(ubyte);
This generates an error, as this function template matches two
instances, but currently I
Is there any elegant/smart solution to reference counting
resources without ever freeing any objects?
When the ref hits 0 it should free some other resource that isn't
memory...
Resource[10] resources;
resources[3].inc; // 1 ref - 0->1 transition enable some feature
resources[3].dec; // 0
On Sunday, 30 August 2020 at 20:12:41 UTC, Arjan wrote:
On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote:
Looking for a full-time or part-time gig? Not only is Symmetry
Investments hiring D programmers, they are also generously
funding two positions for ecosystem work under the D
On Sunday, 28 June 2020 at 16:31:35 UTC, Avrina wrote:
On Sunday, 28 June 2020 at 02:52:03 UTC, Mike Parker wrote:
If that's not good enough for you, then I have nothing else to
say on the matter.
Replies like this one and andrei are why.
You are directing a community around a topic to an
Consider a complex key that is a combination of multiple
variables.
struct key
{
intfoo = 1;
string bar = "joy";
string baz = "huzza";
}
The value is a very large object.
struct value
{
int[4096] payload;
}
There are 10.000s of different keys.
But typically only ~10 different
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote:
Glad to announce D 2.067.0.
https://dlang.dawg.eu/downloads/dmd.2.067.0/
-Martin
Congrats! Although, I must admit, I was a little saddened to see
that multiple alias this didn't make the release, I thought it
was finalized... I
On Wednesday, 6 August 2014 at 00:47:28 UTC, Walter Bright wrote:
If you build dmd in debug mode, and then run it with -O --c, it
will give you a list of all the data flow transformations it
does.
But the list is a blizzard on non-trivial programs.
Awesome, thanks! Will give it a whirl, as
On Monday, 4 August 2014 at 01:26:10 UTC, Daniel Gibson wrote:
Am 04.08.2014 03:17, schrieb John Carter:
But that's OK.
Because I bet 99.999% of those warnings will be pointing
straight at
bone fide defects.
Well, that would make the problem more acceptable..
However, it has been argued
On Friday, 18 July 2014 at 17:40:23 UTC, Timon Gehr wrote:
On 07/18/2014 12:00 AM, Trass3r wrote:
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it
also allow
this?
It could, and I think
The beta works great this far, just sharing some few initial
surprises.
1) The lookup rules for namespaces seem overly permissive:
extern (C++, A.B.C):
void cpp() { }
All these work:
A.cpp
B.cpp
C.cpp
A.B.cpp
B.C.cpp
A.B.C.cpp
2) We have std.traits.functionLinkage, but no corresponding trait
On Monday, 30 June 2014 at 07:47:22 UTC, Lionello Lunesu wrote:
Latest [1] now also supports CTFE:
const i = foo ? -1 : 33;
if (i)
static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
static assert(i == 0); // Works now!
static
On Friday, 13 June 2014 at 16:49:26 UTC, Andrei Alexandrescu
wrote:
Virtual by default will not change. Being able to negate the
final: label is nice to have but not a must. Adding a keyword
for that doesn't scale - it would mean we'd need to add one
keyword to undo each label.
Andrei
On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d
wrote:
On 18 April 2014 04:10, Kagamin via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via
Digitalmars-d wrote:
void f(void* ptr)
{
// was ptr allocated with malloc, or
On Tuesday, 15 April 2014 at 19:44:39 UTC, John Colvin wrote:
On Tuesday, 15 April 2014 at 19:40:50 UTC, Walter Bright wrote:
On 4/15/2014 12:14 PM, Steven Schveighoffer wrote:
On Tue, 15 Apr 2014 14:41:36 -0400, Steven Schveighoffer
schvei...@yahoo.com
wrote:
On Tue, 15 Apr 2014 13:01:40
On Tuesday, 15 April 2014 at 20:40:05 UTC, Walter Bright wrote:
I had a PR for that, but nobody liked it.
https://github.com/D-Programming-Language/dmd/pull/1877
If I correctly understand the reservations raised against this
PR, the people objecting might have agreed to attribute inference
On Sunday, 6 April 2014 at 02:33:38 UTC, Walter Bright wrote:
On 4/5/2014 6:26 PM, Michel Fortin wrote:
What if you also have a C++ foo at global scope?
It'll work exactly the same as import does.
module cpptest;
extern (C++) void foo();
extern (C++, namespace = A) void foo();
On Saturday, 5 April 2014 at 20:47:29 UTC, Walter Bright wrote:
On 4/2/2014 3:07 PM, Walter Bright wrote:
One downside of this proposal is that if we ever (perish the
thought!) attempted
to interface to C++ templates, this design would preclude that.
Yes, this seems to be a fatal flaw.
On Friday, 4 April 2014 at 19:43:56 UTC, Walter Bright wrote:
C++:
namespace S { namespace T {
int foo();
namespace U {
int foo();
}
} }
D:
extern (C++, S::T) {
int foo();
extern (C++, U) {
int foo();
}
}
foo(); //
On Tuesday, 1 April 2014 at 18:35:50 UTC, Walter Bright wrote:
Try this benchmark comparing various classification schemes:
-
Original program... 3 4 1
10x as many iterations... 36 47 19
I think this benchmark is flawed...
1) Apparently there are rounding
On Monday, 31 March 2014 at 17:11:48 UTC, dennis luehring wrote:
Am 28.03.2014 19:27, schrieb Andrei Alexandrescu:
Facebook is open-sourcing warp, a fast C and C++ preprocessor
written by
Walter Bright.
currently any ideas why clang could be 40% faster?
On Monday, 31 March 2014 at 21:16:47 UTC, Walter Bright wrote:
On 3/31/2014 2:06 PM, bearophile wrote:
Walter Bright:
Since then, I've fixed a handful of bugs, but that didn't
amount to much time.
Have you kept a list of such bugs/mistakes of yours for warp?
It is an
interesting list.
Projects such as Pegged and our CTFE regex engine often serve as
poster-children of what is possible in D and many agree they are
among the more important projects.
I was thinking, after std.lexer is accepted, we have a stable
interface, but no matter how great the code is and even if it
On Sunday, 23 February 2014 at 12:07:40 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP56
Manu has needed always inlining, and I've needed never
inlining. This DIP proposes a simple solution.
yay, all for it! The DIP should probably specify what happens if
inlining fails, i.e. generate
On Sunday, 23 February 2014 at 12:57:00 UTC, Walter Bright wrote:
On 2/23/2014 4:25 AM, Tove wrote:
The DIP should probably specify what happens if inlining fails,
i.e. generate a compilation error.
I suspect that may cause problems, because different compilers
will have different inlining
On Sunday, 23 February 2014 at 21:53:43 UTC, Walter Bright wrote:
I'm aware of that, but once you add the:
version(BadCompiler) { } else pragma(inline, true);
things will never get better for BadCompiler. And besides, that
line looks awful.
If I need to support multiple compilers and if
On Wednesday, 12 February 2014 at 20:10:42 UTC, Jacob Carlborg
wrote:
(First off, I hate the name better C, any suggestions?)
-no-runtime
good choice and even if Walter is blocked on higher prio issues,
we can still make it happen as a community.
On Wednesday, 12 February 2014 at 20:23:55 UTC, Kagamin wrote:
On Sunday, 9 February 2014 at 21:12:57 UTC, Jonathan M Davis
wrote:
And you get more memory out of
the deal even if you have as little as 4GB in the box. I wish
that everything
would move to 64-bit so that we wouldn't have to even
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote:
I believe the first code example a newbie sees when he/she
first visits dlang.org should be some variation of Walter's
showcase on Component Programming including all the bells and
whistles of lazy evaluted ranges.
IMHO, this
On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
I've toyed with this idea for a while, and wondered what the
interest there is in something like this.
The idea is to be able to use a subset of D that does not
require any of druntime or phobos - it can be linked merely
with
On Tuesday, 4 February 2014 at 20:34:29 UTC, Andrei Alexandrescu
wrote:
I'm happy to announce that Scott Meyers will deliver a keynote
talk at the upcoming DConf 2014. Details of the talk are
forthcoming.
wow, this is fantastic news! *cheer*
On Sunday, 2 February 2014 at 09:56:06 UTC, Marc Schütz wrote:
auto x = *p;
if(!p) {
do_something(x);
}
In the first step, the if-block will be removed, because its
condition is known to be false. After that, the value stored
into x is unused, and the dereference can get removed too.
On Saturday, 11 January 2014 at 09:51:57 UTC, Peter Alexander
wrote:
On Thursday, 9 January 2014 at 22:53:02 UTC, qznc wrote:
For the visitation API design: Your map approach (bool[Vertex]
m_visited) is probably the most generic one.
A variant, where the nodes store the flag internally is
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote:
S yeah, this is pretty much a pure win all around to my
eyes. Am I blind to the suck?
Wow, great trick! I'd love to see this merged.
On Thursday, 7 November 2013 at 16:25:47 UTC, Brad Anderson wrote:
On Thursday, 7 November 2013 at 08:58:50 UTC, tester wrote:
how do make that comiler work?
[Issue 11457] New: Cannot compile 64bit apps with Visual
Studio 2013
this is a desaster for me. was that release tested? if i amand
On Sunday, 3 November 2013 at 21:21:04 UTC, Joseph Rushton
Wakeling wrote:
On Saturday, 2 November 2013 at 22:45:13 UTC, Ali Çehreli wrote:
I spent considerable amount of time on those names. Like you,
I am not happy with Inverse. :)
I'm not a native English speaker, but FWIW I would have
On Monday, 21 October 2013 at 01:48:56 UTC, Walter Bright wrote:
On 10/20/2013 5:59 PM, Jonathan M Davis wrote:
If that paradigm is frequent enough, it might be worth
wrapping it in a
struct. Then, you'd probably get something like
StaticArray!(int, 10) tmp(n);
int[] a = tmp[];
which used
On Sunday, 20 October 2013 at 19:42:29 UTC, Walter Bright wrote:
On 10/20/2013 12:23 PM, bearophile wrote:
Walter Bright:
No. But I do know that alloca() causes pessimizations in the
code generation, and it costs many instructions to execute.
Allocating fixed size things on the stack
On Thursday, 3 October 2013 at 11:04:26 UTC, Dicebot wrote:
Yes.
( I have not found any rules that prohibit review manager from
voting :) )
I'd love to say yes, since I've been dreaming of the day when we
finally have a lexer... but I decided to put my yes under the
condition that it can
A very minimal example:
template ctfe(alias any)
{
alias ctfe = any;
}
double ms(double val) pure nothrow @property
{
if(__ctfe)
return val / 1000.0;
else
assert(false);
}
The above allows for writing...
ctfe!(10.ms)
... which is in natural reading order as opposed to...
On Tuesday, 1 October 2013 at 11:42:20 UTC, Tove wrote:
A very minimal example:
template ctfe(alias any)
{
alias ctfe = any;
}
double ms(double val) pure nothrow @property
{
if(__ctfe)
return val / 1000.0;
else
assert(false);
}
Turns out it was quite easy to solve...
void
On Tuesday, 17 September 2013 at 09:52:37 UTC, Iain Buclaw wrote:
(gdb) print ('test.enum_ulong')3
$11 = (test.enum_ulong.kE2 | test.enum_ulong.kE3)
(gdb) print ('test.enum_ulong')2
$12 = test.enum_ulong.kE3
What do you think? Is module.name.member too verbose, or
just right? :-)
Regards
On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by
Brian Schott
I remember reading there were some interesting hash-advances in
dmd recently.
http://forum.dlang.org/thread/kq7ov0$2o8n$1...@digitalmars.com?page=1
On Tuesday, 10 September 2013 at 06:42:06 UTC, Walter Bright
wrote:
https://github.com/D-Programming-Language/visuald
Congratulations to Rainer Schuetze and collaborators for this
great work!
Horray! Great news.
Some initial nit-picking:
According to
On Tuesday, 10 September 2013 at 18:10:33 UTC, Rainer Schuetze
wrote:
Thanks for pointing these out. The README didn't receive a lot
of attention lately, most of the documentation and news is on
the web site. I agree, with it being displayed on the front
github page it should be updated.
On Sunday, 8 September 2013 at 09:24:52 UTC, Michael wrote:
On Sunday, 8 September 2013 at 09:15:52 UTC, Namespace wrote:
I'm against it. More important than such a gimmick are the
many open bugs, auto ref, AA, scope, etc. And don't forget the
implementation of the virtual keyword.
+1
I
Wouldn't this style be an acceptable compromise instead? with
both declaration and definition 100% identical.
struct S
{
// member function declarations
static int mfunc1(int a, int b = 5) pure;
static int mfunc2(int a, int b = 5) pure;
static int mfunc3(int a, int b = 5) pure;
//
On Sunday, 8 September 2013 at 18:13:52 UTC, Simen Kjaeraas wrote:
In response to Walter's DIP47 I have created my own take on
what I see as the main problem:
http://wiki.dlang.org/DIP48
Destroy!
I like it but would prefer
@interface instead of interface
Since using interface in this way,
On Tuesday, 27 August 2013 at 21:21:31 UTC, Timon Gehr wrote:
- Safe alloca wrapper using the alloca default argument hack
together with this. (i.e. bearophile's dynamically-sized
strongly typed stack-based arrays.)
Oh Yes please! I've been waiting for this for a long time, there
even was
On Wednesday, 14 August 2013 at 08:48:23 UTC, Jacob Carlborg
wrote:
On 2013-08-14 10:19, Tyler Jameson Little wrote:
- Typo: NonSerialized example should read NonSerialized!(b)
No, it's not a typo. If you read the documentation you'll see
that:
If no fields or this is specified, it
On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote:
Even with a conservative target like C89-only, there are still
an incredibly large number of extremely useful D features (OOP,
templates, scope(exit), CTFE, mixins, ranges, op-overloading,
etc) that DO come for free.
I love the idea
On Saturday, 1 June 2013 at 10:18:27 UTC, Benjamin Thaut wrote:
I've taken a look at core.simd and I have to say is unuseable.
In a very small test program I already found 3 bugs
1) Using debug symbols together with core.simd will cause a ICE
On Saturday, 1 June 2013 at 10:57:03 UTC, Benjamin Thaut wrote:
Am 01.06.2013 12:52, schrieb Tove:
does this generate better code?
float4 v = __vector([1.0f, 2.0f, 3.0f, 4.0f]);
That doesn't even compile. You can try it out yourself using:
http://dpaste.dzfl.pl/
Kind Regards
Benjamin Thaut
On Friday, 31 May 2013 at 08:45:08 UTC, Dicebot wrote:
On Thursday, 30 May 2013 at 18:06:03 UTC, Walter Bright wrote:
about the changelog. Andrej Mitrovic has done a super awesome
job with the changelog, and it is paying off big time.
I am very happy to be proven wrong about it.
It is so
On Friday, 10 May 2013 at 21:04:32 UTC, Idan Arye wrote:
On Wednesday, 8 May 2013 at 20:11:34 UTC, Idan Arye wrote:
OK, so I'm gonna go ahead and implement it, so I can show by
example that the string solution can be typesafe, scalable and
elegant.
OK, this is a basic implementation:
On Sunday, 5 May 2013 at 07:22:06 UTC, Jonathan M Davis wrote:
Now, I argued that pure's primary benefit isn't really in
optimizations but
rather in the fact that it guarantees that your code isn't
accessing global
state, but there's still the general concern that there's a lot
of new
On Saturday, 4 May 2013 at 18:33:04 UTC, Walter Bright wrote:
Runtime Detection
There are still a few cases that the compiler cannot statically
detect. For these a runtime check is inserted, which compares
the returned ref pointer to see if it lies within the stack
frame of the exiting
On Friday, 26 April 2013 at 21:01:17 UTC, Brian Schott wrote:
On Friday, 26 April 2013 at 06:01:27 UTC, Walter Bright wrote:
The real issue is do you want to have the implicit conversions:
0 = false
1 = true
or would you require a cast?
The idea of a true number and a false number doesn't
On Wednesday, 24 April 2013 at 02:18:07 UTC, Luís Marques wrote:
Consider:
sort!(a b)(array);
how about?
sort!(q{a b})(array);
http://dlang.org/lex.html#TokenString
On Wednesday, 24 April 2013 at 12:38:19 UTC, Andrei Alexandrescu
wrote:
On 4/24/13 6:27 AM, Diggory wrote:
Anyway, it seems in general that everyone thinks DIP25A should
be
implemented, or am I mistaken?
I'd like to work a bit more on it before a formal review.
Andrei
If you find the time
On Tuesday, 23 April 2013 at 07:18:41 UTC, Diggory wrote:
I'd still like someone to explain how exactly scope ref would
differ from ref if DIP25/DIP35 were implemented.
If the only difference is that scope ref can accept rvalues
then why would you ever use normal ref? There are no extra
On Tuesday, 23 April 2013 at 09:06:52 UTC, deadalnix wrote:
On Tuesday, 23 April 2013 at 08:41:16 UTC, Tove wrote:
DIP25 imposes a number of code-breaking restrictions even in
@system code, if DIP36 was in place, one could consider
imposing the DIP25 restrictions only in SafeD.
Furthermore
On Monday, 22 April 2013 at 20:02:12 UTC, Andrei Alexandrescu
wrote:
4. Above all this is a new language feature and again we want
to resort to adding new feature only if it is clear that the
existing features are insufficient and cannot be made
sufficient. In particular we are much more
On Friday, 12 April 2013 at 15:43:27 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 04:14:15 -0400, Manu turkey...@gmail.com
I'd use string[].
You mean with format a=b? I suppose that's possible, though
horrible to work with before passing in. Plus what happens if
you have [a=b,
On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 15:26:12 -0400, Tove t...@fransson.se
wrote:
So for the most convenient/common case, you want to add an
allocation?
with the original proposal there is one anyway...
But with my suggested approach
On Friday, 12 April 2013 at 20:52:55 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 16:32:37 -0400, Tove t...@fransson.se
wrote:
On Friday, 12 April 2013 at 20:24:05 UTC, Steven Schveighoffer
wrote:
On Fri, 12 Apr 2013 15:26:12 -0400, Tove t...@fransson.se
wrote:
So for the most
On Wednesday, 27 February 2013 at 18:55:37 UTC, timotheecour
wrote:
Please let me know what you think.
spontaneously... I love it!
On Sunday, 17 February 2013 at 03:26:13 UTC, js.mdnq wrote:
Would it ever be possible to compile D source directly to java
to take advantage of what java offers. (e.g., the ability to
run d code inside a browser)
I'm not talking about necessarily fully fledged
functionality(obviously stuff
On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic
wrote:
On 2/6/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
That's why some of us have suggested
making it so that you can mark variables with @property.
What Jonathan means is this:
struct S
{
int var; // modifiable, can
On Sunday, 10 February 2013 at 14:42:50 UTC, kenji hara wrote:
2013/2/10 kenji hara k.hara...@gmail.com
Why I argue that the syntax `alias this = sym;` is wrong?
Because:
Benefits of the proposed syntax are:
2a. It is consistent with class inheritance syntax `class C : B
{}`.
2b. It is
On Wednesday, 6 February 2013 at 21:40:00 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
Also the DIP argues that addressOf solves the @property issue
w.r.t.
return values. I've proposed we use an .addressOf property
which only
works on @property functions, and I saw
On Saturday, 9 February 2013 at 03:13:47 UTC, Michel Fortin wrote:
It's really great to not have to write boilerplate functions
when default behaviour is perfectly fine. I've been using
Objective-C for a while now and the recent changes where it
automatically synthesize a variable, a getter,
On Monday, 4 February 2013 at 16:01:45 UTC, Steven Schveighoffer
wrote:
@property int foo();
auto x = foo; // error
int delegate() x = foo; // ok
-Steve
I was going to submit the same suggestion, but didn't find time
to until just now.
gets my vote.
On Friday, 1 February 2013 at 11:06:02 UTC, Walter Bright wrote:
On 1/30/2013 8:44 AM, Dmitry Olshansky wrote:
In allocation scheme I proposed that ID could be a 32bit
offset into the unique
identifiers chunk.
That only works if you know in advance the max size the chunk
can ever be and
On Monday, 28 January 2013 at 23:58:40 UTC, Walter Bright wrote:
On 1/28/2013 3:30 PM, Era Scarecrow wrote:
On Monday, 28 January 2013 at 23:11:11 UTC, Walter Bright
wrote:
http://www.drdobbs.com/cpp/implementing-half-floats-in-d/240146674
Anyone care to do the reddit honors?
[quote]
and
On Tuesday, 22 January 2013 at 08:02:26 UTC, Rainer Schuetze
wrote:
type : {
mangled : PPPi,
pretty : int***,
}
I would favour plain type : int***.
Consider it will be parsed from many different languages, C#,
Java... etc and the generic tools may be able to handle
On Wednesday, 9 January 2013 at 20:16:04 UTC, Andrei Alexandrescu
wrote:
On 1/9/13 12:09 PM, Mehrdad wrote:
It's memory-safe too. What am I missing here?
What you're missing is that you define a store that doesn't
model object references with object addresses. That's what I
meant by
On Monday, 7 January 2013 at 10:19:45 UTC, Jacob Carlborg wrote:
On 2013-01-06 23:33, Philippe Sigaud wrote:
Good thinking. It's not pretty but it works. Thanks.
Maybe it can be hidden inside a template?
Yeah, I'll see what I can do.
in which context does private fail? I'm using
On Monday, 7 January 2013 at 13:36:47 UTC, Jacob Carlborg wrote:
On 2013-01-07 12:59, Tove wrote:
in which context does private fail? I'm using something like
this:
struct my_struct
{
private:
@(1) int t1;
@(2) int t2;
@(3) int t3;
}
foreach(m; __traits(allMembers, my_struct
On Friday, 21 December 2012 at 16:28:35 UTC, Andrei Alexandrescu
wrote:
use text based formats for performance sensitive data!
Of course, maybe the 15% claim was pure exaggeration. I really
hope
that's the case.
Text representation has its own advantages.
Andrei
interesting, does it
On Friday, 30 November 2012 at 14:09:48 UTC, foobar wrote:
Why not simplify?
static this()
{
import std.stdio, a, c; // existing syntax
...
}
static this()
{ // no imports - no dependencies
...
}
The current behavior should just be dropped.
+2
Simple Elegant.
On Thursday, 15 November 2012 at 22:04:27 UTC, David Nadlinger
wrote:
On Thursday, 15 November 2012 at 08:45:49 UTC, Tove wrote:
I disagree, you can always fallback to using user defined
types... but it _allows_ for native types also, i.e. more
flexible.
You are missing the point: In your
On Friday, 16 November 2012 at 10:41:44 UTC, Walter Bright wrote:
The whole point of my example was no, you do not necessarily
know the meaning of a user-defined type that is used as an
attribute.
Agree. Imagine we have 3 generic libs/modules...
Optimized CTFE Polygon Primitive Lib, Math, Gfx
On Wednesday, 14 November 2012 at 23:57:38 UTC, David Nadlinger
wrote:
Also, your solution is more complex than simply using types,
yet less flexible: What if you want to use uint attributes
from two libraries on the same type?
David
I disagree, you can always fallback to using user defined
On Wednesday, 14 November 2012 at 11:08:04 UTC, Leandro Lucarella
wrote:
Can you provide one concrete case where it makes sense NOT to
restrict UDAs to
types and it's different from restricting exception to classes
derived from
Exception?
Thank you.
There was the example with Thrift...
On Wednesday, 14 November 2012 at 12:33:58 UTC, Jacob Carlborg
wrote:
I assume you mean something like:
struct UserProfile {
[1] i32 uid;
[2] string name;
[3] string blurb;
}
In that case I would much rather prefer this:
struct UserProfile {
@Id(1) i32 uid;
@Id(2) string
On Wednesday, 14 November 2012 at 13:03:18 UTC, David Nadlinger
wrote:
On Wednesday, 14 November 2012 at 11:18:28 UTC, Tove wrote:
There was the example with Thrift...
struct UserProfile {
1: i32 uid,
2: string name,
3: string blurb
}
service UserStorage
On Wednesday, 14 November 2012 at 06:52:57 UTC, Rob T wrote:
On Wednesday, 14 November 2012 at 02:01:56 UTC, Jonathan M
Davis wrote:
Is there anything like C++ conversion operators in D? I have
used conversion ops in C++ and may want to use a similar
feature in D if available.
--rt
it would
On Wednesday, 7 November 2012 at 08:41:48 UTC, Walter Bright
wrote:
New version up now with a couple reported problems with UDA
fixed.
I may have found a little glitch...?
mixin([1] int a;);
[[2] int b;] int c;
mixin(__traits(getAttributes, c)[0]);
pragma(msg, __traits(getAttributes, a)); =
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright wrote:
References:
http://www.digitalmars.com/d/archives/digitalmars/D/Custom_attributes_again_163042.html
http://www.digitalmars.com/d/archives/digitalmars/D/custom_attribute_proposal_yeah_another_one_163246.html
Inspired by a gallon
Tooo much fun! Argh, _must_ _stop_ _playing_ and actually work ;(
[int a;]
class A
{
}
class B : A
{
mixin(__traits(getAttributes, typeof(super))[0]);
}
can't wait to see all the creative uses this will enable!
On Tuesday, 6 November 2012 at 13:14:50 UTC, Adam D. Ruppe wrote:
On Tuesday, 6 November 2012 at 07:55:51 UTC, Walter Bright
wrote:
User Defined Attributes (UDA) are compile time expressions
that can be attached to a declaration.
Hmmm, it didn't work on the most important place for my use
On Tuesday, 6 November 2012 at 15:19:53 UTC, Walter Bright wrote:
On 11/6/2012 7:14 AM, Tove wrote:
Hmmm, actually it doesn't work in plain function/block scope
either.
Right, I don't see a compelling purpose for that, either.
Hmm, what about library based GC annotations?
[GC.NoScan] int
On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote:
On 2012-10-07 19:32, Namespace wrote:
amazing, good work...! what license is this under, is it allowed
to be used commercially?
On Friday, 5 October 2012 at 13:47:00 UTC, monarch_dodra wrote:
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis
wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
[SNIP]
Regarding definition of variables in D language constructs,
there
is one situation where sometimes
On Friday, 5 October 2012 at 00:22:04 UTC, Jonathan M Davis wrote:
On Friday, October 05, 2012 02:08:14 bearophile wrote:
Tommi:
Maybe we forget about commas then, and extend if-clauses so
that you can properly define variables at the beginning of
it.
Separated by semicolons.
Regarding
On Friday, 21 September 2012 at 04:44:58 UTC, Andrei Alexandrescu
wrote:
Andrei Alexandrescuseewebsiteforem...@erdani.org wrote:
My claim is unremarkable. All I'm saying is the minimum running
time of an algorithm on a given input is a stable and
indicative proxy for the behavior of the
On Friday, 24 August 2012 at 11:18:55 UTC, Dmitry Olshansky wrote:
C's scanf is a poor argument as it uses pointers instead of ref
(and it can't do ref as there is no ref in C :) ). Yet it
doesn't allow to read things in a couple of calls AFAIK. In C
scanf returns number of arguments
On Friday, 10 August 2012 at 12:32:28 UTC, bearophile wrote:
This second D version uses the same class definitions, but
allocates the class instances on the stack. The code is bug
prone and ugly. The other disadvantages are unchanged:
void main() {
import std.stdio;
import
On Thursday, 24 May 2012 at 15:43:57 UTC, Alex Rønne Petersen
wrote:
We just need a dispose pattern whereby explicit dispose()
instructs the GC to not finalize.
So I'm curious, what resource are we trying to free here?
None. I just came across it in the docs and found it completely
1 - 100 of 148 matches
Mail list logo
