On 1/4/2021 4:11 AM, 9il wrote:
[...]
The reason those switches are provided is because the write/read is a
performance hog.
D provides a couple functions in druntime which guarantee rounding intermediate
values to float/double precision. Those can be used as required. This is better
than a
On Tuesday, 5 January 2021 at 03:20:16 UTC, Walter Bright wrote:
On 1/4/2021 4:11 AM, 9il wrote:
[...]
The reason those switches are provided is because the
write/read is a performance hog.
D provides a couple functions in druntime which guarantee
rounding intermediate values to
On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad
wrote:
YOU DO HAVE TO ACKNOWLEDGE A TYPE SYSTEM BUG!
If an indirection through an alias causes type unification to
fail then that is a serious type system failure. No excuses
please...
Different people have different definitions
On Monday, 4 January 2021 at 22:14:12 UTC, welkam wrote:
Anyway you want assign template name. Spoiler alert Bar!int is
not a name. It's also not a type or even an object. You might
used another term for how alias should work but I cant track
them all. Its template instantiation.
It is a
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote:
it makes things overly complicated
Just because a feature makes something simpler is not enough of
an argument of why it should be added. Case and point C, lua and
Go languages. They are popular in part because they are simple.
That's
On Monday, 4 January 2021 at 21:07:49 UTC, welkam wrote:
[snip]
P.s. Thank you for a well written post with a link to useful
read.
Thanks for reading it.
On Monday, 4 January 2021 at 22:55:28 UTC, Ola Fosheim Grøstad
wrote:
"BarInt", "Bar!int" and "Foo!int" are all names, or labels, if
you wish. And they all refer to the same object: the nominal
type. Which you can test easily by using "is(BarInt==Foo!int)".
If the terminology is difficult,
On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad
wrote:
On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote:
I suppose the answer would be that D doesn't pretend to
support all C++ template features and the bug is not a bug
because we live with this somehow for years.
But it
On Monday, 4 January 2021 at 05:58:09 UTC, Walter Bright wrote:
On 1/3/2021 8:37 PM, 9il wrote:
I didn't believe it when I got a similar answer about IEEE
floating-point numbers: D doesn't pertinent to be IEEE 754
compatible language and the extended precision bug is declared
to be a language
On Monday, 4 January 2021 at 05:58:09 UTC, Walter Bright wrote:
On 1/3/2021 8:37 PM, 9il wrote:
I didn't believe it when I got a similar answer about IEEE
floating-point numbers: D doesn't pertinent to be IEEE 754
compatible language and the extended precision bug is declared
to be a language
On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad
wrote:
On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote:
I suppose the answer would be that D doesn't pretend to
support all C++ template features and the
On Monday, 4 January 2021 at 09:21:02 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim Grostad
wrote:
On Monday, 4 January 2021 at 04:37:22 UTC, 9il wrote:
I suppose the answer would be
On 04.01.21 15:44, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
You didn't replace "Bar!int" with "Foo!int". You replaced "Bar!T" with
"Foo!T". That's something else entirely.
No, it isn't.
Of course it is. Replacing foo with bar is not the same as
On Monday, 4 January 2021 at 15:15:50 UTC, ag0aep6g wrote:
As far as I understand, describing what DMD does as
"unification" would be a stretch. You might have a point saying
that DMD should do "plain regular unification" instead of the
ad hoc, undocumented hacks it does right now.
On Monday, 4 January 2021 at 15:25:13 UTC, Atila Neves wrote:
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim
Grøstad wrote:
1. acknowledgment of the issue
2. acknowledgment of what the issue leads to in terms of
inconvenience
3. a forward looking vision for future improvements
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
An alias is a short hand. If it is possible to discriminate by
the alias and the actual object then that it a semantic problem.
Typo: "discriminate between". An alias should be
indistinguishable from the object, you are
On Monday, 4 January 2021 at 15:03:05 UTC, jmh530 wrote:
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
On 04.01.21 15:37, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2021 at 14:11:28 UTC, ag0aep6g wrote:
`Bar!int` is an alias. It's indistinguishable from
`Foo!int`. The code
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
[...]
I am not speaking for Ilya, but from skimming through the
dialogue it struck me that you didn't respond from the
perspective of managing the
On Monday, 4 January 2021 at 14:11:28 UTC, ag0aep6g wrote:
`Bar!int` is an alias. It's indistinguishable from `Foo!int`.
The code fails in the same manner when you replace "Bar!int"
with "Foo!int".
Wrong. This succeeds:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Foo!T x) {}
On Monday, 4 January 2021 at 14:44:00 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
You didn't replace "Bar!int" with "Foo!int". You replaced
"Bar!T" with "Foo!T". That's something else entirely.
No, it isn't. When it is instantiated you get
On Monday, 4 January 2021 at 12:35:12 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 09:21:02 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 09:18:50 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 05:55:37 UTC, Ola Fosheim
Grostad wrote:
On Monday, 4 January
On Monday, 4 January 2021 at 12:35:12 UTC, John Colvin wrote:
What's the simplest example that doesn't work and is that
simple example just indirection through an alias or is it
actually indirection through a template that *when
instantiated* turns out to be just an alias?
Indirection
On 04.01.21 15:37, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2021 at 14:11:28 UTC, ag0aep6g wrote:
`Bar!int` is an alias. It's indistinguishable from `Foo!int`. The code
fails in the same manner when you replace "Bar!int" with "Foo!int".
Wrong. This succeeds:
struct Foo(T) {}
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
You didn't replace "Bar!int" with "Foo!int". You replaced
"Bar!T" with "Foo!T". That's something else entirely.
No, it isn't. When it is instantiated you get "Bar!int" and then
the unification would substitute that with "Foo!int".
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
On 04.01.21 15:37, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2021 at 14:11:28 UTC, ag0aep6g wrote:
`Bar!int` is an alias. It's indistinguishable from `Foo!int`.
The code fails in the same manner when you replace "Bar!int"
with
On 04.01.21 14:47, Ola Fosheim Grøstad wrote:
Indirection through a parametric alias. This is the simplest I have come up
with so far:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
f(Bar!int());
}
On 04.01.21 14:54, Ola Fosheim Grøstad wrote:
On 04.01.21 16:03, jmh530 wrote:
IMO, this is a better example, even if it's a little more verbose.
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto x = Bar!int();
f(x);
}
To be sure that I'm not missing anything: You just added the temporary
`x`,
On Monday, 4 January 2021 at 17:24:42 UTC, John Colvin wrote:
in your opinion, this should compile and msg `int int`, yes?
It does match:
template Q(A : Foo!int) {
pragma(msg, A.stringof);
}
So in then it should also match Foo!T, yes?
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 12:35:12 UTC, John Colvin wrote:
What's the simplest example that doesn't work and is that
simple example just indirection through an alias or is it
actually indirection through a template that
On Monday, 4 January 2021 at 17:22:55 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
[...]
I have a longer reply I'm trying to write, but just to make
sure I'm on the right track:
template Foo(T) {
alias Foo = T;
}
On Monday, 4 January 2021 at 15:53:44 UTC, Atila Neves wrote:
I wasn't a process-oriented answer, nor do I think it should
have been. The PR was a change to the compiler with an
accompanying DIP. I'm a fan of giving an opinion early to save
everyone a lot of work and bother.
All management
On Monday, 4 January 2021 at 17:24:53 UTC, jmh530 wrote:
Your point is basically that a template alias only becomes an
actual alias when it has been instantiated. You then note that
the deduction process operates in terms of Bar (in that you
have to find a T that fits Bar!T to get to an alias
On Monday, 4 January 2021 at 15:42:05 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 15:25:13 UTC, Atila Neves wrote:
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim
Grøstad wrote:
1. acknowledgment of the issue
2. acknowledgment of what the issue leads to in terms of
On Monday, 4 January 2021 at 15:31:02 UTC, ag0aep6g wrote:
On 04.01.21 16:03, jmh530 wrote:
IMO, this is a better example, even if it's a little more
verbose.
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto x = Bar!int();
f(x);
}
To be sure that
On Monday, 4 January 2021 at 17:24:42 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 17:22:55 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
[...]
I have a longer reply I'm trying to write, but just to make
sure I'm on the right track:
On Monday, 4 January 2021 at 17:58:35 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 4 January 2021 at 17:24:42 UTC, John Colvin wrote:
in your opinion, this should compile and msg `int int`, yes?
It does match:
template Q(A : Foo!int) {
pragma(msg, A.stringof);
}
So in then it should
36 matches
Mail list logo
