On 07/13/2014 07:51 PM, Brian Rogoff wrote:
On Sunday, 13 July 2014 at 17:24:40 UTC, Timon Gehr wrote:
On 07/13/2014 06:45 PM, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
Wrong. There are things which are simply bad ideas.
E.g. in this case, Egyptian-style braces definitely make
On 07/13/2014 08:51 PM, Meta wrote:
That's weird, I always assumed this worked. Was it always the case that
numeric types can't be implicitly casted to bool?
Yes, unless their range fits into [0,2).
On 07/11/2014 10:39 PM, Dicebot wrote:
Key difference is that type of string literal is immutable(char)[] so it
is perfectly legal to keep it in binary text segment. Type of array
literal is just T[] (int[] here) and you can possibly mutate their
elements. Because of this each assignment of
On 06/29/2014 11:31 AM, Rene Zwanenburg wrote:
On Sunday, 29 June 2014 at 08:52:36 UTC, Uranuz wrote:
import std.stdio;
string getByName(string name)
{
return smth;
}
template getByName(string name)
{
enum getByName = .getByName(name);
}
void main()
{
writeln(getByName!(name));
On 06/02/2014 09:06 AM, dennis luehring wrote:
i want to port this C++ code to good/clean D and have no real idea how
to start
contains 2 templates - a slice like and a binary reader for an slice
main idea was to copy the immutablity of the slice data to the reader
http://pastebin.com/XX2yhm8D
On 06/02/2014 04:30 PM, captaindet wrote:
This doesn't work, because a delegate needs a context it can capture,
which is available only inside of a function.
so the real explanation is that a module as such has no context. much of
the module design has the look and feel as if it were some
On 06/01/2014 09:59 AM, Philippe Sigaud via Digitalmars-d-learn wrote:
On Sun, Jun 1, 2014 at 12:34 AM, Timon Gehr via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
This behaviour is independent of templates. Struct values of the same size
can be reinterpret-cast to each other
On 05/31/2014 11:21 PM, Paul D Anderson wrote:
On Saturday, 31 May 2014 at 20:14:59 UTC, bearophile wrote:
Miles Stoudenmire:
In contrast to those two examples where immutable can be used at compile
time, what are some other cases where it is necessary to use enum
instead of immutable?
By
On 06/01/2014 12:25 AM, Ali Çehreli wrote:
dec10 little = cast(dec10(bingo));
You meant cast(dec10)(bingo).
assert(little == dec10(123.45));
Is this expected behavior?
Paul
That is surprising. I've discovered that if the template has members
that depend on a template parameter than the
On 05/20/2014 11:04 PM, anonymous wrote:
On Tuesday, 20 May 2014 at 20:15:09 UTC, Dominikus Dittes Scherkl
wrote:
/// create a fixed size array with the given name and with *max* entries
max + 1 entries
/// of immutable values of the same type as the return value of the
/// given function.
On 05/20/2014 11:48 PM, Timon Gehr wrote:
This achieves the same:
template lookupTable(alias fn,uint max=255){
static assert(maxuint.max);
enum ReturnType!fn[max+1] lookupTable=iota(0,max+1).map!fn.array;
}
(Though I'd never actually do template argument checking in a static
On 05/07/2014 12:07 PM, Yuriy wrote:
On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote:
On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:
Hello, is there any way to static if(__ctfe)? I want to declare class
members which are only available in ctfe. Thanx.
Sadly not as far as
On 05/04/2014 12:58 PM, Marc Schütz schue...@gmx.net wrote:
This means that you will still get a (bit-wise) copy if you pass in an
r-value. But semantically, this is a move, not a copy, so it is
potentially cheaper than a copy (if your type has an expensive postblit).
It can be constructed
On 05/04/2014 04:56 PM, Tim Holzschuh via Digitalmars-d-learn wrote:
Am 03.05.2014 21:47, schrieb Timon Gehr via Digitalmars-d-learn:
On 05/03/2014 08:20 PM, Tim Holzschuh via Digitalmars-d-learn wrote:
Let me know if you also want hints on how to get the logic right.
Would be very nice
On 05/03/2014 12:34 AM, Tim Holzschuh via Digitalmars-d-learn wrote:
Most probably this isn't a wrong use of something D-specific
Some of the problems are:
@property Lexer lexer() pure { return _lexer; }
If you change the result of a call to 'lexer' this will not change
'_lexer'. Mark the
On 05/03/2014 08:20 PM, Tim Holzschuh via Digitalmars-d-learn wrote:
Let me know if you also want hints on how to get the logic right.
Would be very nice!
While 2*2 works, 2+2 throws an Error because the number-method gets an
END-Token instead of a Number-Token (although I'm not sure why).
On 04/08/2014 05:14 PM, Steven Schveighoffer wrote:
On Mon, 07 Apr 2014 18:30:30 -0400, Matej Nanut matejna...@gmail.com
wrote:
Hello,
I don't understand why so many break statements are needed in this
construct:
immutable key = 3;
switch (key)
{
foreach (c; TypeTuple!(1,
On 04/17/2014 03:15 PM, Steven Schveighoffer wrote:
But should a foreach over a tuple a breakable statement?
Well, it is a foreach statement.
It is on the other hand not too clear what to do about 'static foreach',
but I am leaning towards banning non-labelled break and continue inside
On 04/17/2014 08:04 PM, Matej Nanut wrote:
The expansion with gotos explains the behaviour nicely! Cool.
The error about fall-through is still missing though?
Good point, this error should probably be triggered. I guess the problem
is roughly that indeed every case statement in the code is
On 04/09/2014 07:27 PM, Kagamin wrote:
On Saturday, 5 April 2014 at 21:33:30 UTC, Timon Gehr wrote:
The issue asks for delegates to be typed properly, unless I
misunderstand what 'properly' means here.
Isn't the issue in pure nested functions treated as strongly pure?
What does it have to do
On 04/06/2014 05:28 AM, dnspies wrote:
int[][] nested;
nested ~= null;
~ is overloaded, so how does it know what type I intend null to be? How
can I specify it?
(int[]).init
On 04/05/2014 11:53 AM, bearophile wrote:
John Colvin:
I think there's an argument that this should work, on the grounds that
the context pointer is just another argument and therefore the lambda
can be weakly pure.
Was this discussed in the forum?
I've been bringing this up time and time
On 04/05/2014 10:33 PM, Artur Skawina wrote:
On 04/05/14 21:51, Timon Gehr wrote:
On 04/05/2014 11:53 AM, bearophile wrote:
John Colvin:
I think there's an argument that this should work, on the grounds that
the context pointer is just another argument and therefore the lambda
can be weakly
On 03/28/2014 08:00 PM, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f that
needs to return ranges of different types (but identical element types):
auto f(A...)(A args) {
...
if (someCondition)
On 03/29/2014 01:37 AM, Artur Skawina wrote:
You can wrap the range in a common one. When the above approach isn't
enough, there's always the next level:
(Note that your code does not actually compile.)
On 03/29/2014 06:19 PM, Artur Skawina wrote:
Of course it compiles -- with the compiler version I happen to use...
The compiler situation is one of the main reasons I gave up on D
about a year ago. Every release introduces a new dialect. This may
not be such a big problem for trivial toy
On 03/20/2014 10:25 PM, Ali Çehreli wrote:
This is a somewhat common little exercise: Write a function that takes
the size of a diamond and produces a diamond of that size.
When printed, here is the output for size 11:
*
***
*
***
*
***
*
On 02/27/2014 10:09 PM, Ben Jones wrote:
My question is: which features of the D range abstraction allow zip to
work the way we expect?
Assignable elements of a range do not need to be addressable.
What C++isms were left behind to make this work?
In C++, iterators should implement
On 02/28/2014 12:38 AM, Nordlöw wrote:
Does anybody know where in the DMD source I can figure out if the return
value of a function call is used or not?
I'm not familiar with the DMD source code, but a good way to proceed is
usually to grep for existing error messages that are somehow
On 02/17/2014 08:22 PM, simendsjo wrote:
Should the following two uses be a compile-time error?
foreach(i; 10 .. 0) // Never executes
foreach(i; iota(10, 0)) // .. neither does this
I would like the second to either be a compile-time error or
automagically use a negative step.
So we
On 02/17/2014 08:33 PM, simendsjo wrote:
On Monday, 17 February 2014 at 19:30:38 UTC, Timon Gehr wrote:
On 02/17/2014 08:22 PM, simendsjo wrote:
Should the following two uses be a compile-time error?
foreach(i; 10 .. 0) // Never executes
foreach(i; iota(10, 0)) // .. neither does this
I
On 02/17/2014 09:21 PM, simendsjo wrote:
On Monday, 17 February 2014 at 20:03:32 UTC, Timon Gehr wrote:
...
It was just to illustrate the issue more clearly. Eg. it means one and
the same iota expression can sometimes iterate in one direction and in
the other direction at other times. That's
On 02/17/2014 10:12 PM, simendsjo wrote:
Ok, I yield. I just happened to write
foreach(i; 10 .. 0)
and was suprised that it didn't give any warnings or errors.
But I still somewhat stand by my point: Dead code is illegal in D,
(No it is not. Some forms of dead code are detected by DMD,
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise?
No, this is fine.
On 02/16/2014 04:13 PM, Timon Gehr wrote:
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise
On 02/16/2014 04:40 PM, bearophile wrote:
Timon Gehr:
assert(S(1)S(2)); // passes. ok.
assert(S(int.min)S(int.max)); // passes. oops.
A possible solution is to add to Phobos (unless it's already there) a
variadic templated funcion cmpBuilder() that accepts an even number of
arguments
On 02/15/2014 05:30 PM, Denis Mezhov wrote:
Please help. How to convert DList!string to string array?
auto a = DList!string();
a.insertFront(123);
a.insertFront(abc);
string[] b = a[];
Array!string c = a[];
Don't work.
auto b = a[].array;
Array!string c;
c.insertBack(a[]);
On 02/15/2014 06:11 PM, Jakob Ovrum wrote:
...
You can construct containers from ranges directly:
auto c = Array!string(a[]);
This seems obvious, but it is not actually true.
On 02/15/2014 07:23 PM, Jakob Ovrum wrote:
On Saturday, 15 February 2014 at 18:14:00 UTC, Timon Gehr wrote:
On 02/15/2014 06:11 PM, Jakob Ovrum wrote:
...
You can construct containers from ranges directly:
auto c = Array!string(a[]);
This seems obvious, but it is not actually true
On 02/08/2014 10:46 AM, Nick Sabalausky wrote:
This works:
--
void foo(T)(T t) if(is(T==char)) {}
void foo(T)(T t) if(is(T==int )) {}
void main() { foo(1); }
--
But if I move the int version to a different module, and try to alias
it
On 01/26/2014 10:59 AM, Pierre Talbot wrote:
Hi,
I was wondering why CTFE is context sensitive, why don't we check
every expressions and run the CTFE if it applies?
When does it apply?
On 01/23/2014 02:39 AM, Jakob Ovrum wrote:
On Thursday, 23 January 2014 at 01:17:19 UTC, Timon Gehr wrote:
On 01/16/2014 06:56 AM, Jakob Ovrum wrote:
Note that the Unicode definition of an unqualified character is the
translation of a code *point*, which is very different from a *glyph
On 01/16/2014 06:56 AM, Jakob Ovrum wrote:
Note that the Unicode definition of an unqualified character is the
translation of a code *point*, which is very different from a *glyph*,
which is what people generally associate the word character with.
Thus, `string` is not an array of characters
On 01/14/2014 08:50 PM, bearophile wrote:
Currently D refuses code like this:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
}
void main() {}
With two repeated error messages:
test1.d(3): Error: pure nested function 'bar' cannot access mutable data
'a'
On 01/14/2014 09:21 PM, David Nadlinger wrote:
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return bar;
}
On 01/14/2014 09:41 PM, David Nadlinger wrote:
On Tuesday, 14 January 2014 at 20:36:43 UTC, Timon Gehr wrote:
Yes, it should.
https://d.puremagic.com/issues/show_bug.cgi?id=9148
And, of course, you are right. ;) I missed the analogy to member
functions w.r.t. the implicit context parameter
On 01/11/2014 09:35 AM, Casper Færgemand shortt...@hotmail.com wrote:
On Saturday, 11 January 2014 at 07:50:51 UTC, Jakob Ovrum wrote:
Your problem is probably better solved without string mixins, but we'd
probably need to see some code or more elaboration to accurately
suggest a solution.
On 01/05/2014 03:55 PM, Philippe Sigaud wrote:
Is there any plan to add indexing on runtime indices to Tuple? It can
be done, by generating a specific runtime opIndex for Tuple, if the
types held in the tuple have a common type.
It would override the current index operator.
On 12/30/2013 10:15 PM, Ilya Yaroshenko wrote:
On Monday, 30 December 2013 at 12:24:28 UTC, lomereiter wrote:
Use Y combinator?
http://forum.dlang.org/thread/mailman.157.1385247528.2552.digitalmars-d-le...@puremagic.com#post-l6rgfq:24g5o:241:40digitalmars.com
This is not lambda =(
I want
On 12/30/2013 11:50 PM, Meta wrote:
enum factorial5=(function int(a)=a==0?1:a*__traits(parent,{})(a-1))(5);
(In D, you need to specify the return type for a recursive function
declaration. If one doesn't here, DMD crashes, which is a bug.
https://d.puremagic.com/issues/show_bug.cgi?id=11848)
On 12/29/2013 11:11 PM, David Held wrote:
On 12/28/2013 5:13 AM, Timon Gehr wrote:
[...]
I wouldn't call this an 'eager map'. It's a shallow wrapper around a
foreach loop.
The point being that foreach loops aren't composable.
Dave
Wrapping it will not change that.
On 12/28/2013 10:17 AM, David Held wrote:
On 12/27/2013 7:32 PM, Marco Leise wrote: [...]
Side effects and altering the input object itself makes me
want to pull out my crucifix. You shall not have impurity in
your functional style code!
Why not? There are many impure functional
On 12/27/2013 05:54 AM, Jonathan wrote:
Thanks to everyone that has replied.
@Timon Gehr:
Thank you. In reply to [1]: that is an interesting issue that I don't
really understand right now. Can you explain exactly where I invoke
undefined behavior? It was my understanding that structs
On 12/27/2013 02:45 PM, bearophile wrote:
Timon Gehr:
mixin ADT!q{ Term: Var char | Op char Term[] };
void main(){
const expr = Op('f', [Op('g',[Var('x'), Var('y')]), Op('a',[]),
Var('x')]);
}
Where is ADT defined?
https://d.puremagic.com/issues/show_bug.cgi?id=10431
(And why isn't
On 12/27/2013 05:08 PM, Jonathan wrote:
Let me just check my understanding: If a function says it returns a
thing of type T, it really does return something whose outermost shape
is T; however, if it contains pointers to other things, and these were
stack allocated, the pointers might be
On 12/27/2013 01:40 AM, Jonathan wrote:
Term makeExTerm(){
Term var1 = Term(1);//x
Term var2 = Term(2);//y
Term var3 = Term(3);//z
Term fxx = Term(4, [var1,var1]);//f(x,x)
Term gfxxy = Term(5, [fxx,var2]);//g(f(x,x),y)
Term hzg = Term(6,
On 12/27/2013 02:49 AM, bearophile wrote:
In almost-theory D should allow code like:
import std.stdio, std.typecons, std.variant;
alias Term = Algebraic!(string, Tuple!(string, This[]));
void main() {
const expr = Term(tuple(f, [Term(tuple(g, [x.Term,
y.Term])), Term(tuple(a, [])),
On 12/25/2013 04:57 PM, Casper Færgemand shortt...@hotmail.com wrote:
From http://dlang.org/declaration.html#Parameter
Parameter:
InOutopt BasicType Declarator
InOutopt BasicType Declarator ...
InOutopt BasicType Declarator = DefaultInitializerExpression
InOutopt Type
On 12/23/2013 10:34 PM, John Carter wrote:
So I resolved to learn D, and try code as idiomatically as I could.
So here is a trivial module that encodes and decodes roman numerals.
https://bitbucket.org/JohnCarter/roman/src/9ec5b36b9973426f35b0ab9dfd595cb3b305e39e/roman.d?at=default
I also
On 12/24/2013 12:36 PM, Dfr wrote:
Let's say i have array of kind:
auto a = [[1,FF], [2, 00FF00], ...];
Is there simple way to turn it into associative array of kind:
string[string] b = [1: FF, 2: 00FF00, ...];
void main(){
import std.array, std.algorithm, std.typecons;
On 12/24/2013 02:37 PM, monarch_dodra wrote:
On Tuesday, 24 December 2013 at 07:08:49 UTC, David Held wrote:
Ok, let's make it more interesting...
The compiler is only supposed to error out on stuff that is actually
illegal according to the language.
What you are doing is not *illegal*, it
On 12/24/2013 01:48 AM, H. S. Teoh wrote:
Agreed. Note that introducing assignment into the mix may not help
matters, but complicate them even more. For example:
int x=1, y=0;
writeln((y = ++x) + (++y--) * (x=y)); // what does this print?
...
'y-- is not an lvalue'.
Assuming
On 12/24/2013 06:46 PM, H. S. Teoh wrote:
...
What is strict left to right evaluation, since * has to be evaluated
before +? Or you consider all side-effects to be evaluated first (from
left to right), and then the expression?
It is about the order operands are evaluated in.
Eg. if you have
On 12/21/2013 09:56 PM, Nick Hamann wrote:
I'm not sure if this is a bug or if I'm doing something wrong.
Compilation succeeds and the program runs successfully with this code:
import std.stdio;
import std.conv : to;
void main() {
auto x = std.conv.to!double(7.3);
writeln(x - 2.2);
}
On 12/20/2013 04:45 PM, Frustrated wrote:
I'm in need of a circular buffer/array. I am using std.container.array
to avoid the GC. I suppose I could copy and modify the code but is there
any easier way? ...
What prevents you from implementing your buffer using an
std.container.Array as the
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot cleaner.
On 12/20/2013 09:42 PM, monarch_dodra wrote:
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I
On 12/20/2013 10:57 PM, Timon Gehr wrote:
Most non-trivial templates that use is(typeof(...)) in the constraint
can be broken. (In the sense that it is possible to instantiate them
even though their body does not compile.)
Actually, it seems that the behaviour of DMD has changed
On 12/18/2013 12:27 PM, Andrea Fontana wrote:
I have an internal compiler error in my code. I can't reduce code to
reproduce this problem, but I remember there was a tool that can do
this, what's its name? Where can I download that tool?
https://github.com/CyberShadow/DustMite
On 12/10/2013 08:29 AM, Kenji Hara wrote:
This is an intended behavior. An array literal has dynamic array type
*by default*.
But all of literals in D behave as polymorphic.
char c = 'A'; // character literal has char type by default
dchar d = 'A'; // but it may be implicitly typed as
On 12/06/2013 02:06 AM, H. S. Teoh wrote:
On Thu, Dec 05, 2013 at 10:06:55PM +0100, Timon Gehr wrote:
On 12/05/2013 07:26 PM, Jonathan M Davis wrote:
The best that could be done would be to warn about the comparison
or to make it an error.
http://d.puremagic.com/issues/show_bug.cgi?id=259
On 12/05/2013 07:26 PM, Jonathan M Davis wrote:
The best that could be done would be to warn about the comparison
or to make it an error.
http://d.puremagic.com/issues/show_bug.cgi?id=259
...
The best that could be done would arguably be to simply do the
comparison the 'right' way. E.g.
On 12/04/2013 12:49 AM, Max Klyga wrote:
range.map(...).flatten.map(...) might look similar and it could be
possible to squeeze monads to work with this api, but the thing is that
not every monad could provide a meaningful map function
Yes, every monad provides a meaningful way to map
On 12/04/2013 12:02 AM, Shammah Chancellor wrote:
I get the gist of that, but it seems like the range concept with UFCS
provides the same thing? E.G. range.map().flatten().map()?
Well, informally speaking, this is roughly an instance of a Monad.
Does it really not accomplish the same
On 11/22/2013 01:29 PM, Jonathan M Davis wrote:
On Friday, November 22, 2013 11:50:57 Andrea Fontana wrote:
I just mean:
int t = s.value; // Means int t = s.value!int;
If there's a problem with template instantiatio is the same we
have now.
Now I have to write:
int t = s.value!int;
so if
On 11/22/2013 02:43 PM, Jonathan M Davis wrote:
On Friday, November 22, 2013 14:29:46 Timon Gehr wrote:
The request would be reasonable if 'value' was declared as follows though:
@property T value(T)() if (is(T == int)) { return _intValue; }
i.e. the fact that the template argument equals
On 11/22/2013 02:50 PM, Dicebot wrote:
On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
I assumed that it knows - when is trying to instatiate s.value
template - that s.value is part of an assignment and that it will be
assigned to an int.
This is somewhat wrong part.
On 11/11/2013 04:52 AM, Timothee Cour wrote:
The code snippet below doesn't work. Is there a way to make it work?
import std.stdio;
void main(){
writelnIfNonVoid(writeln(ok));
}
void writelnIfNonVoid(T...)(T a){
static if(T.length)
writeln(a);
}
import std.stdio;
void main(){
On 11/11/2013 02:06 PM, Timon Gehr wrote:
Or, if you care about evaluation order and locking stdout:
This was a little too quick. It does not work too well since if the last
parameter is of type void, the newline is emitted before the trailing
arguments of type void are evaluated, which may
On 11/10/2013 09:03 PM, Colin Grogan wrote:
For example,
Column!(int, int) randonNumberColumn = new Column!(int, int)((ref
m)=to!string(uniform(m.vars[0], m.vars[1])), 1, 10);
will work.
However,
Column!(int, int) incrementalNumberColumn = new Column!(int,
int)((ref
On 11/09/2013 10:12 AM, Rob T wrote:
I am wondering if there's a way to pass only the variable and have the
inspect function determine the variable's symbol name as passed rather
than have to pass both the name and value separately?
...
Well, yes, but the following does not scale that well,
On 11/10/2013 01:51 AM, Timon Gehr wrote:
On 11/09/2013 10:12 AM, Rob T wrote:
I am wondering if there's a way to pass only the variable and have the
inspect function determine the variable's symbol name as passed rather
than have to pass both the name and value separately?
...
Well, yes
On 11/08/2013 07:12 AM, Benjamin Thaut wrote:
The problem is that you define the struct Thing as a inner struct.
struct Thing only exists in the decompiled version, not in the original
source. So far it looks like a bug to me.
On 11/07/2013 12:07 AM, H. S. Teoh wrote:
// This is possibly the single nastiest bit of syntax in all of D:
static if (is(func X == __parameters)) {
// Quick, without looking at the docs: what does X refer
// to?
Nothing.
On 11/05/2013 05:00 PM, bearophile wrote:
1) I usually write more than one class or struct inside each D module,
unlike in Java. But sometimes when I move that class or struct elsewhere
(during refactoring, or in other situations) I get access errors to
private fields. Those errors were already
On 11/06/2013 04:34 AM, Tyro[17] wrote:
I’m sure the following table is missing a few items but am unclear
what they are. For starters these , =, , , !, !=
belong on the table but I’m not sure where. I am also not sure if
these ..., @, # belong there at all. There might be other errors
or
On 10/31/2013 10:19 PM, Ali Çehreli wrote:
...
Y Combinator? (No, I have not solved it yet. :) )
http://rosettacode.org/wiki/Y_combinator#D
Ali
Oh my god, my eyes!
auto y(S,T...)(S delegate(T) delegate(S delegate(T)) f){
struct F{ S delegate(T) delegate(F) f; alias f this; }
On 10/21/2013 02:58 PM, John Colvin wrote:
I suspect I'm being very dumb here, but I can't get my head around this:
template B(alias A)
{
alias B = A;
}
template C(A ...)
{
alias C = A[0];
}
static assert(B!1 == 1); //fine
static assert(C!1 ==
On 09/29/2013 10:25 PM, Martin Drasar wrote:
Hi,
I have upgraded to dmd 2.063.2 and have some troubles making my custom
bidirectional range work (it used to). In fact, even this code fails on
assert and I am not really sure why...
...
I get this when trying to compile:
drasar@uriel:/tmp$ dmd
On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
...
After I've seen a pretty cool demo of clang-modernize
(http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
to attack this and similar problems is to add a class hierarchy
analyzer: a command-line utility that is fed an
On 09/10/2013 01:46 PM, Timon Gehr wrote:
On 09/10/2013 02:28 AM, Andrei Alexandrescu wrote:
...
After I've seen a pretty cool demo of clang-modernize
(http://clang.llvm.org/extra/ModernizerUsage.html), I think the best way
to attack this and similar problems is to add a class hierarchy
On 08/16/2013 06:14 AM, Ali Çehreli wrote:
I know of three places a TypeTuple can be used at:
1) Function parameter list
2) Template parameter list
In fact, no.
template A(Seq!(int,int) a){ enum A=a[0]; } // error
3) Array literal element list
Are there more?
...
I assume you mean
On 08/16/2013 01:09 PM, Timon Gehr wrote:
- Arguments to string mixins:
mixin(Seq!int x=2;); // error
fixed.
On 08/11/2013 06:25 AM, JS wrote:
Given an object, is there a built in way to get the size of the class
the object represents?
Yes.
On 08/11/2013 05:28 PM, JS wrote:
On Sunday, 11 August 2013 at 13:40:41 UTC, Timon Gehr wrote:
On 08/11/2013 06:25 AM, JS wrote:
Given an object, is there a built in way to get the size of the class
the object represents?
Yes.
Troll.
http://en.wikipedia.org/wiki/Troll_(Internet)
You seem to show a certain amount of sophistication in projecting your
own attributes on others. Why not retarget that creativity to achieve
something useful?
On 08/05/2013 03:59 PM, jicman wrote:
Greetings!
I have this code,
foreach (...)
{
if (std.string.tolower(fext[0]) == doc ||
std.string.tolower(fext[0]) == docx ||
std.string.tolower(fext[0]) == xls ||
std.string.tolower(fext[0]) == xlsx ||
std.string.tolower(fext[0])
On 08/03/2013 03:50 AM, Syniurge wrote:
Turning it into an enum works.
I still have no idea why assigning an AA literal to an immutable AA
isn't acceptable,
It is a bug in the compiler implementation
but since it's only used at compile time it's probably
better to make it an enum.
Indeed.
On 08/02/2013 01:34 AM, hunt wrote:
Hello, guys. It is weird to ask about my homework here, but I haven't
gotten a proper answer yet. It's about D feature...maybe..
http://dpaste.dzfl.pl/905d6ad7
Question is that Investigate how D allows you to defend your definition
of Map so that it may be
On 07/14/2013 11:37 AM, lomereiter wrote:
I assume that you template ends up creating a dummy interface though
and this isn't really acceptable.
Yes, it does. Once ':' is typed, some inheritance must occur.
Nope.
template Seq(T...){ alias T Seq; }
class C : Seq!(){ }
Why isn't a dummy
101 - 200 of 838 matches
Mail list logo
