On Tuesday, 5 January 2021 at 15:10:29 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 January 2021 at 15:04:34 UTC, welkam wrote:
>> Also how "i'm like you" is an insult?
>
> I don't think I should reply to this…

Then dont replay to this sentence. My post had more than one sentence.

Also the thing where I showed that what you said for days is not possible and is a bug is actually possible if you followed D's syntax and semantics. I guess it had nothing to do with your loss of motivation to discuss this topic further.

This code compiles

struct bar(T) {}
void f(T)(bar!T x) {}

void main()
{
    alias fooInt = bar!int;
    alias foo = bar;

    assert(is(fooInt  == bar!int));
    assert(is(foo!int == bar!int));
    assert(is(fooInt  == foo!int));
}

On Tuesday, 5 January 2021 at 21:03:40 UTC, welkam wrote:
> This code compiles
>
> struct bar(T) {}
> void f(T)(bar!T x) {}
>
> void main()
> {
>     alias fooInt = bar!int;
>     alias foo = bar;
>
>     assert(is(fooInt  == bar!int));
>     assert(is(foo!int == bar!int));
>     assert(is(fooInt  == foo!int));
> }

This code has no relation to what we discuss in this thread…

On Wednesday, 23 December 2020 at 22:13:09 UTC, Ola Fosheim Grøstad wrote:
> The big picture that the DIP suggested was that when stuff like this fails to compile:
>
>   struct Foo(T) {}
>
>   alias Bar(T) = Foo!T;
>
>   void f(T)(Bar!T x) {}
>
>   void main() {
>     auto foo = Bar!int();
>     f(foo);
>   }
>
> Then most programmers would just conclude that the compiler is broken beyond repair and move on to another language.

Replace alias Bar(T) = Foo!T; with alias Bar = Foo;

struct Foo(T) {}

alias Bar = Foo;

void f(T)(Bar!T x) {}

void main() {
    auto foo = Bar!int();
    f(foo);
}

On Tuesday, 5 January 2021 at 21:43:09 UTC, welkam wrote:
> Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
>
> struct Foo(T) {}
>
> alias Bar = Foo;
>
> void f(T)(Bar!T x) {}
>
> void main() {
>     auto foo = Bar!int();
>     f(foo);
> }

The example was a reduced case. One can trivially construct examples where that won't work.

It is very useful to create a simple alias from a complex type for export from a type library, then it breaks when people use that type library to write templated functions.

People do this all the time in C++.

On Tuesday, 5 January 2021 at 21:46:34 UTC, Ola Fosheim Grøstad wrote:
> It is very useful to create a simple alias from a complex type for export from a type library, then it breaks when people use that type library to write templated functions.
>
> People do this all the time in C++.

Example:

// library code

struct _config(T){}
struct _matrix(T,C){}

alias matrix(T) = _matrix!(T,_config!T);


// application code

void f(T)(matrix!T m){}

void main()
{
    f(matrix!float());
    f(matrix!double());
}

On Tuesday, 5 January 2021 at 21:46:34 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 5 January 2021 at 21:43:09 UTC, welkam wrote:
>> Replace alias Bar(T) = Foo!T; with alias Bar = Foo;
>>
>> struct Foo(T) {}
>>
>> alias Bar = Foo;
>>
>> void f(T)(Bar!T x) {}
>>
>> void main() {
>>     auto foo = Bar!int();
>>     f(foo);
>> }
>
> The example was a reduced case. One can trivially construct examples where that won't work.
>
> It is very useful to create a simple alias from a complex type for export from a type library, then it breaks when people use that type library to write templated functions.
>
> People do this all the time in C++.

I reread the whole thread. You want something like this except without mixins and to actually work.

struct Foo(T) {}

mixin template Bar(T) {
     Foo!T
}

void f(T)(Foo!T x) {}

void main() {
    f(mixin Bar!(int)());
}

In languages you can pass things by value, by reference or by name. Alias works by the name passing mechanic. You can not use alias or capture by name here because you cant get a name of something that doesn't exist yet.

What you want is parametric generation of definition and insertion in place. Now that's something Walter can understand.

On 1/5/2021 5:30 AM, Guillaume Piolat wrote:
> It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform.

That same argument could be use to always use float instead of double. I hope you see it's fallacious <g>


> What about this plan?
> - use SSE all the time in DMD

That was done for OSX because their baseline CPU had SSE.

> - drop real :)

No.

On 1/5/2021 2:42 AM, 9il wrote:
> On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote:
>> On 1/4/2021 11:22 PM, 9il wrote:
>>> I can't reproduce the same DMD output as you.
>>
>> I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors.
>>
>> https://issues.dlang.org/show_bug.cgi?id=21526
>>
>>
>>> It just uses SSE, which I think a good way to go, haha.
>>
>> As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision.
> 
> Does this mean that DMD Linux 32-bit executables should compile with SSE codes?

The baseline Linux target does not have SSE.


> I ask because DMD compiles Linux 32-bit executables with x87 codes when -O is passed and with SSE if no -O is passed. That is very weird.

Example, please?

On 06.01.21 03:27, Walter Bright wrote:
> On 1/5/2021 5:30 AM, Guillaume Piolat wrote:
>> It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform.
> 
> That same argument could be use to always use float instead of double. I hope you see it's fallacious <g>
> ...

Evidence that supports some proposition may well fail to support a completely different proposition.

An analogy for your exchange:

G: Birds can fly because they have wings.
W: That same argument could be used to show mice can fly. I hope you see it's fallacious <g>


Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides.

I want to execute the code that I wrote, not what you think I should have instead written, because sometimes you will be wrong. There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis.

On 1/5/2021 9:57 PM, Timon Gehr wrote:
> Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides.
> 
> There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis.

As far as I can tell, the only algorithms that are incorrect with extended precision intermediate values are ones specifically designed to tease out the roundoff to the reduced precision.

I don't know of straightforward algorithms, which is what most people write, being worse off because of more precision.

For example, if you're summing values in an array, the straightforward approach of simply summing them will not become incorrect with extended precision. In fact, it is likely to be more correct.

> I want to execute the code that I wrote, not what you think I should have
> instead written, because sometimes you will be wrong.

With programming languages, it does not matter what you think you wrote. What matters is how the language semantics are defined to work. In writing professional numerical code, one must carefully understand it, knowing that it does *not* work like 7th grade algebra. Different languages can and do behave differently, too.