On Monday, 15 October 2012 at 09:33:23 UTC, Maxim Fomin wrote:
---foo.d---
struct A
{
int i;
alias i this;
}
---bar.d---
int opUnary(string T)(A a) { ... }
...
{
++a;
}
---
I. i is incremented, opUnary is not called. However opUnary
matches better to the actual type and if it
On Sunday, 14 October 2012 at 06:22:03 UTC, Maxim Fomin wrote:
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined
type, then:
++var
gets rewritten as:
var.opUnary!++()
Not always
On Sunday, 14 October 2012 at 07:14:25 UTC, Maxim Fomin wrote:
If this request is approved and compiler has opUnary definition
outside type (which suits better then alias
this) such function would hijack alias this.
Free functions cannot and must not ever hijack, i.e. modify
existing
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites the
expression into a regular method call with a specific name. Then
the regular language rules apply.
According to the
On Saturday, 13 October 2012 at 09:06:28 UTC, Jakob Ovrum wrote:
Do note that this says *method* call. Your example doesn't use
methods. Hence, the current state of operator overloading is
consistent with TDPL.
I don't agree with the last sentence. According to TDPL:
1) whenever at least one
On Saturday, 13 October 2012 at 09:50:05 UTC, Jonathan M Davis
wrote:
It is most definitely _by design_ that you cannot
overload operators except as member functions.
I don't understand this design choice then. I don't see any
problem in allowing UFCS operators. Because of the way UFCS
On Saturday, 13 October 2012 at 11:50:40 UTC, Maxim Fomin wrote:
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
I don't see this as taking UFCS functionality further. Rather,
I think it's simply more logical that with
On Saturday, 13 October 2012 at 16:02:25 UTC, Maxim Fomin wrote:
From my point of view operator overloading methods are
special functions and not treating them as candidates for
UFCS does make more sense.
I can think of only one thing that makes custom operator methods
special or different
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Thus, it would be very logical to assume that it doesn't matter
whether you write:
++var
...or, write the following instead:
The following compiles, which I'm pretty sure must be a bug,
right? Just checking to be sure I won't be polluting the bug
tracker.
void main()
{
auto f = (int i) {};
static assert (!is(f == function)); // should fail
static assert (!is(f == delegate));
}
Although, the only case, where this would be
a problem is with a range of type T, where:
1) It's impossible to provide random access to T
2) T can't return a reference from its 'front' property
3) T is a finite range (not infinite)
4) 'front' property may return the same value at different
On Friday, 5 October 2012 at 09:37:51 UTC, Ali Çehreli wrote:
This brings up a question: Should all range types implement
opEquals() for range equality as opposed to identity
equality of the underlying range (i.e. Take.source in this
case).
But even if the range concept was altered so that
What does 'd' in dchar and dstring stand for?
On Wednesday, 3 October 2012 at 01:21:38 UTC, ixid wrote:
If it were (range, seed) then there would be no problem:
[1,1,1].reduce!a + b + 2(0).writeln; // == 9
My thoughts exactly.
On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic
wrote:
Dissasembly:
__Dmain:; Function begin, communal
enter 12, 0 ;
_ C8, 000C, 00
call_D4test8getFloatFNdZf ; 0004
_ E8,
(rel)
...
Can I
On Saturday, 29 September 2012 at 18:16:24 UTC, Timon Gehr wrote:
This seems to be a DMD bug.
And a pretty serious looking one at that. That bug could make
nukes fly to wrong coordinates, and that just ruins everybody's
day.
One use case I can think of for specializing functions based on
whether or not its arguments are compile-time evaluable:
// Big container that can't be accessed in constant time:
immutable cachedResults = init();
double getResult(args)
if (areCompileTimeConstants!(args) == false)
{
On Friday, 28 September 2012 at 17:52:55 UTC, Tommi wrote:
In a perfect world, I think, the compiler would always evaluate
all possible functions at compile-time, given that doing so
would produce a smaller (or equal size) executable than what
not-evaluating-at-compile-time would produce
On Sunday, 10 June 2012 at 10:16:23 UTC, jerro wrote:
No, but you could wrap it in a template to force it to always
execute at compile time.
So, I just realized, I could have just this one convenience
template that I can use whenever I want to force an expression to
be evaluated at
On Saturday, 25 August 2012 at 20:58:47 UTC, Jonathan M Davis
wrote:
auto buf = file.rawRead(new ubyte[](4));
Could we somehow skip making the temporary buffer, and read from
the file directly into an existing variable. Can we make a slice
of one element that points to an existing value.
On Sunday, 26 August 2012 at 15:18:27 UTC, Timon Gehr wrote:
auto refToBigValue = (g_bigValue)[0..1];
Thanks. Oughta read the f***ing manual instead of glancing
through it:
http://dlang.org/arrays.html
How would you go about retrieving the exact underlying type of
enum?
There's a thorough explanation of how incomplete types work in
C++:
http://www.drdobbs.com/the-standard-librarian-containers-of-inc/184403814
And there's some more C++ related stuff:
http://www.boost.org/doc/libs/1_50_0/doc/html/container/containers_of_incomplete_types.html
I wouldn't know
Hmm.. actually, it seems there have been plenty of reports of
this issue already. Didn't see it the first time:
http://d.puremagic.com/issues/show_bug.cgi?id=6174
How do you make a (deep) copy of a variable of any type? For
example the following attempt at a generic next function doesn't
work, because it modifies its argument if the argument is a
reference type.
T next(T)(in T value)
if (is(typeof(++[T.init][0]) == T))
{
auto copy = cast(T)
On Friday, 13 July 2012 at 18:09:59 UTC, Era Scarecrow wrote:
I would think the best solution is to create a mutable local
version, and then assign the immutable global one when you are
done.
Thanks for the workaround. But I'm actually more interested in
whether or not this is a compiler
The following code doesn't compile. It seems like a compiler bug
to me, but I can't find a bug report about it. Is it a bug?
private immutable(int[]) constants;
shared static this()
{
constants.length = 10;
constants[0] = 123; // Error: constants[0] isn't mutable
}
I'm trying to constrain a struct template based on a parameter
that's supposed be a function with a certain signature. Difficult
to explain, easier just to show the problem:
module pseudorange;
struct PseudoInputRange(T, alias advance)
//The next line doesn't compile
//if
Three related questions:
1) Is there a way to force a function to be always executed at
compile time (when it's possible to do so) no matter what context
it's called in?
2) Is it possible to specialize a function based on whether or
not the parameter that was passed in is a compile time
On Sunday, 10 June 2012 at 10:23:09 UTC, Timon Gehr wrote:
No there is not. You could use a template that calls a private
function at compile time instead. What is your use case?
I was just thinking about a situation where a property
accessor/mutator methods are not as simple as read/assign
30 matches
Mail list logo
