Jump to page: 1 2
Thread overview
UFCS with constructors
Nov 06, 2013
bearophile
Nov 06, 2013
qznc
Nov 06, 2013
bearophile
Nov 07, 2013
bearophile
Nov 06, 2013
Ali Çehreli
Nov 06, 2013
Maxim Fomin
Nov 06, 2013
Ali Çehreli
Nov 06, 2013
Maxim Fomin
Nov 06, 2013
Dicebot
Nov 06, 2013
bearophile
Nov 06, 2013
Dicebot
November 06, 2013
import std.typecons: Typedef;
alias Foo = Typedef!double;
void main() {
    auto a1 = Foo(1);
    pragma(msg, typeof(a1));
    auto a2 = 1.Foo;
    pragma(msg, typeof(a2));
    auto a3 = Foo(-1);
    pragma(msg, typeof(a3));
    auto a4 = -1.Foo;
    pragma(msg, typeof(a4));
}


It prints:

Typedef!(double, nan)
Typedef!(double, nan)
Typedef!(double, nan)
double


Is this expected/acceptable/good?

Bye,
bearophile
November 06, 2013
On Wednesday, 6 November 2013 at 11:04:05 UTC, bearophile wrote:
> import std.typecons: Typedef;
> alias Foo = Typedef!double;
> void main() {
>     auto a1 = Foo(1);
>     pragma(msg, typeof(a1));
>     auto a2 = 1.Foo;
>     pragma(msg, typeof(a2));
>     auto a3 = Foo(-1);
>     pragma(msg, typeof(a3));
>     auto a4 = -1.Foo;
>     pragma(msg, typeof(a4));
> }
>
>
> It prints:
>
> Typedef!(double, nan)
> Typedef!(double, nan)
> Typedef!(double, nan)
> double
>
>
> Is this expected/acceptable/good?

Operator precedence of "." is higher than unary minus. That should be the explanation, why the fourth output is different than the others.

However, what is Typedef for?
November 06, 2013
qznc:

> Operator precedence of "." is higher than unary minus.

Is this good?


> However, what is Typedef for?

It's to create a differently named type, useful for stronger static typing, to increase code clarity and avoid some bugs.

If you have a function like this:

double foo(in double x, in double k) pure nothrow

You can give it swapped arguments (also because D still lacks named arguments). But if you define a:

alias Coordinate = Typedef!double;
Coordinate foo(in Coordinate x, in double k) pure nothrow

You will have less mistakes.

Currently Typedef has some bugs.

Bye,
bearophile
November 06, 2013
On 11/06/2013 03:04 AM, bearophile wrote:
> import std.typecons: Typedef;
> alias Foo = Typedef!double;
> void main() {
>      auto a1 = Foo(1);
>      pragma(msg, typeof(a1));
>      auto a2 = 1.Foo;
>      pragma(msg, typeof(a2));
>      auto a3 = Foo(-1);
>      pragma(msg, typeof(a3));
>      auto a4 = -1.Foo;
>      pragma(msg, typeof(a4));
> }
>
>
> It prints:
>
> Typedef!(double, nan)
> Typedef!(double, nan)
> Typedef!(double, nan)
> double
>
>
> Is this expected/acceptable/good?
>
> Bye,
> bearophile

I would be very surprised if unary "-" produced a different type from the operand:

import std.typecons: Typedef;

alias Foo = Typedef!double;

void main() {
    auto a = 1.Foo;
    auto b = -a;
    static assert (is (typeof(a) == typeof(b)));    // FAILS!
}

After all, we are used to hidden bugs based on that expectation: ;)

void main()
{
    uint a = 1;
    auto b = -a;

    assert(b == uint.max);                  // WT?
    static assert(is (typeof(b) == uint));  // <-- the reason
}

Seriously though, yeah, unary "-" must return Typedef!(double, nan).

Ali

November 06, 2013
On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote:
>
> I would be very surprised if unary "-" produced a different type from the operand:
>
> Ali

Operator does not produce type, it produces value of expression, and type of expression happens not to be the type you expected. But such expectations need not correspond to language rules (try to think from from language laywer perspective). In bearophile case, I guess Typedef!double overloads unary operator which returns double which is primary reason for such behavior.
November 06, 2013
On 11/06/2013 09:46 AM, Maxim Fomin wrote:

> On Wednesday, 6 November 2013 at 17:10:34 UTC, Ali Çehreli wrote:
>>
>> I would be very surprised if unary "-" produced a different type from
>> the operand:
>>
>> Ali
>
> Operator does not produce type, it produces value of expression, and
> type of expression happens not to be the type you expected.

Thanks. That's what I meant. :)

> But such
> expectations need not correspond to language rules (try to think from
> from language laywer perspective).

I still argue that the expression -expr must have the same type as expr.

> In bearophile case, I guess
> Typedef!double overloads unary operator which returns double which is
> primary reason for such behavior.

That's what I deduced from qznc's post and tried to mean that such behavior would be confusing to programmers.

Ali

November 06, 2013
On Wednesday, 6 November 2013 at 18:02:32 UTC, Ali Çehreli wrote:
> > But such
> > expectations need not correspond to language rules (try to
> think from
> > from language laywer perspective).
>
> I still argue that the expression -expr must have the same type as expr.
>
> > In bearophile case, I guess
> > Typedef!double overloads unary operator which returns double
> which is
> > primary reason for such behavior.
>
> That's what I deduced from qznc's post and tried to mean that such behavior would be confusing to programmers.
>
> Ali

I think that reason for such behavior is the way used defined operator overloading functions are implemented, not the language per se, so programmers confuse themselves.
November 06, 2013
On Wednesday, 6 November 2013 at 18:16:04 UTC, Maxim Fomin wrote:
> I think that reason for such behavior is the way used defined operator overloading functions are implemented, not the language per se, so programmers confuse themselves.

What about other possible reason - "Typedef implementation sucks"? ;)
November 06, 2013
Dicebot:

>"Typedef implementation sucks"? ;)

So do you suggest to open some enhancement request/bug report on Typedef?

Bye,
bearophile
November 06, 2013
On Wednesday, 6 November 2013 at 21:57:47 UTC, bearophile wrote:
> Dicebot:
>
>>"Typedef implementation sucks"? ;)
>
> So do you suggest to open some enhancement request/bug report on Typedef?
>
> Bye,
> bearophile

Sure. get enough such reports and we may even get it back as language feature :) (I think getting Typedef to act properly in all cases is damn hard task to do)
« First   ‹ Prev
1 2