On Thursday, 7 January 2021 at 22:15:07 UTC, Ali Çehreli wrote:
On 12/23/20 10:05 AM, 9il wrote:
> It was a mockery executed by Atila
For those who read the above comment but do not want to read
the rest of this long thread, the linked PR discussion does not
contain mockery:
>
On 1/9/2021 11:18 PM, Jacob Carlborg wrote:
On 2021-01-06 03:30, Walter Bright wrote:
The baseline Linux target does not have SSE.
What about this changelog entry:
https://dlang.org/changelog/2.087.0.html#xmm-linux-changelog ?
Eh, you're right. It's FreeBSD32
On 2021-01-06 03:30, Walter Bright wrote:
The baseline Linux target does not have SSE.
What about this changelog entry:
https://dlang.org/changelog/2.087.0.html#xmm-linux-changelog ?
--
/Jacob Carlborg
On 1/6/2021 1:31 AM, 9il wrote:
> [...]
This is the same problem as https://issues.dlang.org/show_bug.cgi?id=21526
It has been provided in the thread
https://forum.dlang.org/post/gqzdiicrvtlicurxy...@forum.dlang.org
In general, I strongly reiterate that posting bugs to the n.g. means they
On 1/6/2021 4:26 AM, Jacob Carlborg wrote:
On 2021-01-06 03:30, Walter Bright wrote:
The baseline Linux target does not have SSE.
Other compilers solve this by having a flag to specify the minimum target CPU.
DMD has flags for that, too.
On 12/23/20 10:05 AM, 9il wrote:
> It was a mockery executed by Atila
For those who read the above comment but do not want to read the rest of
this long thread, the linked PR discussion does not contain mockery:
> https://github.com/dlang/dmd/pull/9778#issuecomment-498700369
Ali
On Wednesday, 6 January 2021 at 12:12:31 UTC, Guillaume Piolat
wrote:
Happened to me once 21 oct 2015 according to my log.
Proof:
https://github.com/AuburnSounds/Dplug/commit/c9a76e024cca4fe7bc94f14c7c1185d854d87947
On 2021-01-06 03:30, Walter Bright wrote:
The baseline Linux target does not have SSE.
Other compilers solve this by having a flag to specify the minimum
target CPU.
--
/Jacob Carlborg
On Wednesday, 6 January 2021 at 12:12:31 UTC, Guillaume Piolat
wrote:
It's really not a problem anymore since using LDC that uses SSE
The other upside being denormals.
On Wednesday, 6 January 2021 at 12:15:25 UTC, Guillaume Piolat
wrote:
The other upside being denormals.
What has also been true though is that with LDC I've not been
able to actually have 80-bit precision with FPU instructions ; no
matter what its FPU control word was. Really not understood
On Wednesday, 6 January 2021 at 02:27:25 UTC, 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
On Wednesday, 6 January 2021 at 06:50:34 UTC, Walter Bright wrote:
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.
It becomes impossible to write good
On Wednesday, 6 January 2021 at 02:30:30 UTC, Walter Bright wrote:
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
On 06.01.21 07:50, Walter Bright wrote:
> 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
On Wednesday, 6 January 2021 at 06:50:34 UTC, Walter Bright wrote:
With programming languages, it does not matter what you think
you wrote. What matters is how the language semantics are
defined to work.
Yes, this is how it's different from communicating natural
languages where the receiver
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,
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
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
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
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);
}
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:
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
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);
}
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));
}
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
On Tuesday, 5 January 2021 at 18:48:06 UTC, ag0aep6g wrote:
On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad
wrote:
My main concern is that we need to attract more people with a
strong comp.sci. background because as a language grow it
becomes more tricky to improve and the most
On Tuesday, 5 January 2021 at 18:06:32 UTC, Ola Fosheim Grøstad
wrote:
My main concern is that we need to attract more people with a
strong comp.sci. background because as a language grow it
becomes more tricky to improve and the most difficult topics
are the ones that remain unresolved (like
On Tuesday, 5 January 2021 at 17:13:01 UTC, ag0aep6g wrote:
Sure. I've said in my first post in this thread that "issue
1807 is well worth fixing/implementing".
Ok, if we have a majority for this, then all is good.
A program has a bug when it doesn't behave as intended by its
author. I think
On 05.01.21 11:44, Ola Fosheim Grøstad wrote:
So, does that mean that you agree that having better unification would
be a worthwhile item to have on a wish list for 2021? So, if somebody
want to do a full implementation that performs well, then it would be an
interesting option?
Sure. I've
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…
On Monday, 4 January 2021 at 22:55:28 UTC, Ola Fosheim Grøstad
wrote:
It is a name, e.g.:
alias BarInt = Bar!int;
"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
On Tuesday, 5 January 2021 at 13:30:50 UTC, Guillaume Piolat
wrote:
On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote:
The only D compiler that uses excess precision is DMD and
only if -O flag is passed. The same example compiled with GDC
uses write-read codes. LDC uses SSE
On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote:
The only D compiler that uses excess precision is DMD and only
if -O flag is passed. The same example compiled with GDC uses
write-read codes. LDC uses SSE codes.
DMD still supports baseline 32 bit Windows that does not have
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote:
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
[snip]
[snip[
Regardless, the DIP likely could have been improved by
mentioning its inclusion in C++ 11 (and perhaps focused a bit
less on implementation).
Yes.
On Monday, 4 January 2021 at 17:48:50 UTC, ag0aep6g wrote:
I think you're hitting the nail on the head here regarding the
confusion. Such a rewrite makes intuitive sense, and it would
be nice, but it doesn't happen.
So, does that mean that you agree that having better unification
would be a
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
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
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 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 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 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 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 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 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 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
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 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: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: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 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 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 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: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 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 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 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 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: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 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 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 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 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: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 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 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 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 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 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 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 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 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 feature.
The "extended precision bug" is how all x87 code
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 is a bug even if there was no C++... An alias should work
by simple
On Sunday, 3 January 2021 at 22:50:16 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
You should put yourself in the boots of Atila. If you accept a
change that later turns out to be bad idea you cant just take
it out.
This is just silly. You don't
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
[snip]
The way I saw it the whole argumentation for a language change
went like this:
9il: This would be helpful for my lib
Atila: Im not convinced this is good addition to the language
Thats it. No more good arguments came later. If
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote:
You should put yourself in the boots of Atila. If you accept a
change that later turns out to be bad idea you cant just take
it out.
This is just silly. You don't have to accept a specific
solution...
...but...
YOU DO HAVE TO
On Sunday, 3 January 2021 at 06:35:23 UTC, 9il wrote:
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:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32
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:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all
On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote:
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
Yes, it wasn't explicit. He
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote:
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
Yes, it wasn't explicit. He
On Thursday, 24 December 2020 at 15:00:16 UTC, jmh530 wrote:
That Foo-ish reminds me of something in D like
static if (__traits(compiles, {
auto temp = Foo!T.init;
}))
Yes, it is similar in spirit. It is pretty much the same as the
C++17 version, but easier to write,
On Thursday, 24 December 2020 at 09:56:50 UTC, Ola Fosheim
Grøstad wrote:
[snip]
I don't use concepts yet as it is a very new C++ feature. The
following code does not work in XCode, although it probably
should according to cppreference. So take this with a grain of
salt (other variations
On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote:
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
Yes, it wasn't explicit. He didn't write bad words, he did a bad
decision. Bad for D.
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
It was a mockery executed by Atila
Read the all comments and didnt saw any mockery
On Thursday, 24 December 2020 at 11:05:16 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
[...]
Non-concept version is more verbose, but yeah, works fine in
C++17:
namespace detail {
template class F, class U>
static constexpr void
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
concept Bar(T) = requires(U)() {
Foo!U; //akin to something like typename T::Foo;
}
where we would basically be telling the compiler that T has to
be a Foo!U, which would mean you would have to use Bar like
Bar!U...at least
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
doing similar things). Abusing C++'s syntax you might have
something like
concept Bar(T) = requires(U)() {
Foo!U; //akin to something like typename T::Foo;
}
where we would basically be telling the compiler that T has to
be a
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
On Wednesday, 23 December 2020 at 21:47:32 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 21:37:11 UTC, Ola Fosheim
Grøstad wrote:
foo.f;
foo.b;
bar.f;
bar.b;
}
argh, forget that... I am tired... Sorry.
template
struct Foo {
};
template
using Bar = Foo;
On Wednesday, 23 December 2020 at 21:37:11 UTC, Ola Fosheim
Grøstad wrote:
foo.f;
foo.b;
bar.f;
bar.b;
}
argh, forget that... I am tired... Sorry.
On Wednesday, 23 December 2020 at 20:56:26 UTC, jmh530 wrote:
On Wednesday, 23 December 2020 at 16:25:58 UTC, 9il wrote:
[snip]
1.
Alias template function parameter resolution
https://github.com/dlang/dmd/pull/9778
[snip]
I gave some thought to potential alternatives, but this is
really the
On Wednesday, 23 December 2020 at 16:25:58 UTC, 9il wrote:
[snip]
1.
Alias template function parameter resolution
https://github.com/dlang/dmd/pull/9778
[snip]
I gave some thought to potential alternatives, but this is really
the simplest way to think about it.
For instance, I would
On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote:
On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
[...]
Yes, if something is perceived as bug it becomes a burden to
remember that it is isn't. Not
On Wednesday, 23 December 2020 at 19:49:44 UTC, aberba wrote:
None of which seems to me we're making it easy for people
without time of their hands to make contribution. Spending
hours-days writing a DIP or pull request that doesn't get the
attention it deserves can be very demoralizing
On Wednesday, 23 December 2020 at 18:38:01 UTC, 9il wrote:
Or that was just a very good mockery. But as was said that
doesn't really matter for the result we have.
True. Other languages try to iron out perceived flaws. I am quite
impressed by how C++ has managed to move, even though it is
On Wednesday, 23 December 2020 at 17:22:28 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 23 December 2020 at 17:08:26 UTC, 9il wrote:
C++ templates can be resolved, at least at the level Mir needs
this. So, it is a bug in my opinion. But it was said the DIP
is required. I can't write DIP
1 - 100 of 124 matches
Mail list logo
