(This is my second attempt, the forums were down the first time…
:-( )
On Wednesday, 4 January 2023 at 02:54:51 UTC, Hipreme wrote:
Hello D Game Developers. As you guys know, I have been
developing a cross platform game engine for some years right
now. I'm close to release version 1.0.
On Thursday, 21 July 2022 at 17:58:17 UTC, Johan wrote:
Godbolt now shows optimization pipeline steps for LDC, giving
great insight into the LLVM optimization process, including
Thanks for pointing this out, this was fun!
On Tuesday, 19 July 2022 at 09:55:52 UTC, Guillaume Piolat wrote:
I put tags in comments, to text search later.
Usually:
```
// TODO: actually blocks a release
```
Yes, this form is also recognized by some editors, might even
compile a todo-list in the IDE interface for you (with no
On Wednesday, 6 July 2022 at 21:30:44 UTC, Dukc wrote:
And I think there is still pretty much value in handling UTF-16
strings because that's what many other languages use. With the
current vision, Phobos V2 won't handle UTF16 in place. We'll
have to convert it to UTF8 before manipulation,
On Tuesday, 5 July 2022 at 11:49:20 UTC, ryuukk_ wrote:
I am sad that no word on the Allocator API, moving forward i
personally think APIs that use memory should be required to ask
for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none
On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote:
https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt
Argh, linking to large files...
My implementation passes this :3
It should be complete test cases.
Well, you also have to test for the cases that should not
On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote:
We have a perfectly good Unicode handling library already.
(Okay, little out of date and doesn't handle Turkic stuff, but
fixable).
The standard one is called ICU.
Yes, that is a common one that is maintained, but maybe there
On Sunday, 3 July 2022 at 20:28:18 UTC, rikki cattermole wrote:
We only support UTF-16/UTF-32 for the target endian.
Text input comes from many sources, stdin, files and say the
windowing system are three common sources that do not make any
such guarantees.
Well, then the application author
On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote:
It is required for string equivalent comparisons (which is what
you should be doing in a LOT more cases! Anything user provided
when compared should be normalized first.
Well, I think it is reasonable for a protocol to require
On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote:
On 04/07/2022 6:10 AM, Ola Fosheim Grøstad wrote:
People who are willing to use 4 bytes per code point are
probably using third party C-libraries that have their own
representation, so you have to convert anyway?
If you use
On Sunday, 3 July 2022 at 17:27:43 UTC, rikki cattermole wrote:
That's going to bite us big time when it comes to Unicode
handling which wants to work with dstring's.
You can just use ints… It is better to do something commonly used
well, than have features that not enough people use to get
On Sunday, 3 July 2022 at 11:39:45 UTC, Mike Parker wrote:
Language evolution doesn't really mean much until we get all of
this sorted.
Good point.
That's right. But Walter wants to minimize its use in Phobos
v2, and there's a strong desire to have a pay-as-you-go
DRuntime. I'm not the
On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:
Feedback is welcome.
Thank you for putting this in clear terms. I miss an overarching
«primary use scenarios» to guide further language evolution. How
do you know if new language features are good or bad if you have
no scenarios to
On Thursday, 23 June 2022 at 06:52:48 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 June 2022 at 06:36:23 UTC, Ola Fosheim Grøstad
wrote:
Track the object instead and don’t change the type of the
pointer to scope.
I guess this is flow typing too, but it is less intrusive to
say that the
On Thursday, 23 June 2022 at 06:36:23 UTC, Ola Fosheim Grøstad
wrote:
Track the object instead and don’t change the type of the
pointer to scope.
I guess this is flow typing too, but it is less intrusive to say
that the object is either of type «scope» or type «heap» and that
regular
On Thursday, 23 June 2022 at 00:45:09 UTC, Steven Schveighoffer
wrote:
I think this is the better option. Either that, or that when it
returns `p` that trumps any possible `scope` inference.
Imagine you have a function like this:
```d
int foo()
{
int x = 0;
x = long.max;
x = 2;
On Wednesday, 22 June 2022 at 21:20:33 UTC, Steven Schveighoffer
wrote:
Full flow analysis will be defeatable by more complex
situations:
```d
int *p = null;
if(alwaysEvaluateToFalse()) p =
else p = new int(5);
return p;
```
That would take a lot of effort just to prove it shouldn't be
On Wednesday, 22 June 2022 at 20:48:13 UTC, Steven Schveighoffer
wrote:
The part about `scope` being shallow. This is a problem.
One thing that will be confusing to most users is that it appears
to be using "taint" rather than proper flow analysis on the
pointed-to-object?
```d
int*
On Wednesday, 22 June 2022 at 19:09:28 UTC, Dukc wrote:
On Tuesday, 21 June 2022 at 15:05:46 UTC, Mike Parker wrote:
The blog:
https://dlang.org/blog/2022/06/21/dip1000-memory-safety-in-a-modern-system-programming-language-pt-1/
Now on 26. place at Hacker News.
This was a nice
On Monday, 6 June 2022 at 11:23:44 UTC, Daniel N wrote:
So Object-C can import C, but *C* cannot import *C*.
Objective-C is a proper superset of C AFAIK.
On Monday, 6 June 2022 at 11:02:32 UTC, Ola Fosheim Grøstad wrote:
Yes, Objective-C has added modules to C since forever… Just
rename your .c file to .m
I guess that would be the first.
Or maybe not… you still use .h, so it depends on the
implementation. Pointless discussion really.
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:
https://clang.llvm.org/docs/Modules.html
And I am out of this thread.
Yes, Objective-C has added modules to C since forever… Just
rename your .c file to .m
I guess that would be the first.
On Monday, 6 June 2022 at 01:05:38 UTC, zjh wrote:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:
Because it's fun to be first!
Yes, `'d'` is always independent.
[C++'s
moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support)
`D`, hurry up and get
On Tuesday, 10 May 2022 at 19:24:25 UTC, Andrea Fontana wrote:
Maybe bambinetto is more about immaturity. Bambinuccio is cute.
Bambinaccio is bad. Bambinone is big (an adult that behave like
a child). -ello doesn't sound good with bambino, but it's very
similar to -etto.
Good luck :)
On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote:
Oh, italian is full of suffixes. -ello means a slightly
different thing. It's small but sounds like a bit pejorative.
Oh, and I loved the sound of it… suggests immaturity, perhaps?
(I love the -ello and -ella endings. «Bambinella»
On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote:
Indeed the "-ino" suffix in "serverino" stands for "small" in
italian. :)
Bambino > bambinello? So, the embedded-version could be
«serverinello»? :O)
On Tuesday, 10 May 2022 at 15:00:06 UTC, Andrea Fontana wrote:
I work in the R and every single time I even have to write a
small api or a simple html interface to control some strange
machine I think "omg, I have to set nginx agaain".
Good point, there are more application areas than
On Tuesday, 10 May 2022 at 12:52:01 UTC, Andrea Fontana wrote:
I'm running a whole website in D using fastcgi and we have no
problem at all, it's blazing fast. But it's not so easy to
setup as serverino :)
Easy setup is probably the number one reason people land on a
specific web-tech, so it
On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote:
And you can still handle 700k/views per hour with 20 workers!
Requests tend to come in bursts from the same client, thanks to
clunky javascript APIs and clutters of resources (and careless
web developers). For a typical D user
On Wednesday, 9 February 2022 at 17:48:29 UTC, Guillaume Piolat
wrote:
There is also the Nim "discard" statement.
Just change the default to not allowing return values to be
discarded. When you really want to, do:
```
cast(void) function_with_return_value(…)
```
Or something like that.
On Wednesday, 9 February 2022 at 10:59:03 UTC, Dukc wrote:
You're implying that your opinion is rational and apolitical,
disagreeing with it is irrational politics.
I am implying that there are many symptoms of people not being
willing to champion the best possible design and instead have
On Sunday, 6 February 2022 at 20:52:21 UTC, Paul Backus wrote:
If you intended to direct your messages at "the community" in
general, rather than at me specifically, you should have
started a new thread. As is, with these messages buried several
pages deep in a thread about a different topic,
On Sunday, 6 February 2022 at 19:14:50 UTC, Paul Backus wrote:
Let me rephrase: I do not understand why you feel the need to
direct these messages at me, personally.
I am sorry if you felt I was addressing you personally. That was
not intended, maybe bad phrasing on my part. (I tend to send
On Sunday, 6 February 2022 at 16:20:07 UTC, Paul Backus wrote:
I did not reply (and do not intend to reply) to any of the
numerous other statements you have made in your other replies
to this thread, since they are statements about the design of
the D language and the DIP process in general,
On Sunday, 6 February 2022 at 15:51:46 UTC, Paul Backus wrote:
If you're still confused *after* you've read the documentation,
feel free to come back and complain to me then.
What I stated has nothing to do with documentation. I think the
semantics are too important to be a "linter-feature".
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
To be honest, though, I can see where he's coming from. When
writing DIP 1038, I made a conscious effort to avoid using the
term "non-`@nodiscard`", due to the double negative. With a
positively-phrased name like `@mustUse`, that
On Sunday, 6 February 2022 at 15:17:35 UTC, Paul Backus wrote:
On Sunday, 6 February 2022 at 14:44:40 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
@mustUse is a user-defined attribute, and the official style
guide says that names of UDAs
On Sunday, 6 February 2022 at 14:56:42 UTC, Paul Backus wrote:
If you strongly prefer the lower-case version, you can always
rename it in your own code:
import core.attribute: mustuse = mustUse;
This response is getting a bit longwinded, and I really want this
feature, but…
1.
On Sunday, 6 February 2022 at 13:33:53 UTC, Paul Backus wrote:
On Sunday, 6 February 2022 at 10:55:20 UTC, Daniel N wrote:
Guess I'm way too late, I just find it very strange you
settled on mixedCase, it's not used for anything else.
(nothrow @nogc). I also don't agree with the motivation
On Friday, 28 January 2022 at 13:27:33 UTC, WebFreak001 wrote:
If there are people that would get upset from removing it, it's
something that shouldn't be removed. (as there are people who
are still interested in the project and might still use it)
I hear what you are saying, but maybe there
On Thursday, 27 January 2022 at 08:52:32 UTC, WebFreak001 wrote:
the list is being maintained, feel free to open PRs to update
links and remove old stuff.
It is probably better that the current maintainers remove stuff,
I think people would get upset if someone else started to wipe
out
On Wednesday, 26 January 2022 at 19:25:18 UTC, Guillaume Piolat
wrote:
On Wednesday, 26 January 2022 at 15:53:44 UTC, Ola Fosheim
Grøstad wrote:
Is this list out of date?
https://github.com/dlang-community/awesome-d
I think it's alright. It's somehow out of date with the game
engines I
On Wednesday, 26 January 2022 at 13:14:49 UTC, Guillaume Piolat
wrote:
Precisely I opened this thread because it's hard to know about
everything that exist in the D ecosystem. I expected tips for
this or that library.
Is this list out of date?
https://github.com/dlang-community/awesome-d
On Tuesday, 25 January 2022 at 08:44:34 UTC, Guillaume Piolat
wrote:
I always read "How good really is X?" as "this is bad"
and "How bad really is X?" as "this is good"
Yes, I think that is pretty universal. Didn't feel anything was
wrong with the title, but the fact that most examples used
On Friday, 14 January 2022 at 18:54:26 UTC, Steven Schveighoffer
wrote:
You might as well say that C is unusable at a high level vs.
javascript because you need to decide what type of number you
want, is it int, float, long? OMG SO MANY CHOICES.
Bad choice of example… C is close to unusable
On Friday, 14 January 2022 at 02:13:48 UTC, H. S. Teoh wrote:
compiler). You can write functional-style code, and, thanks to
metaprogramming, you can even use more obscure paradigms like
declarative programming.
No, you can't. You can do a little bit of weak declarative
programming in C++
On Thursday, 13 January 2022 at 21:32:15 UTC, Paul Backus wrote:
As you correctly observe, D is a great language for programmers
who want autonomy--far better than something like Java, Go, or
Rust, which impose relatively strict top-down visions of how
code ought to be written.
I keep seeing
On Thursday, 13 January 2022 at 16:33:59 UTC, Paulo Pinto wrote:
ARC, tracing GC, whatever, but make your mind otherwise other
languages that know what they want to be get the spotlight in
such vendors.
Go has a concurrent collector, so I would assume it is reasonable
well-behaving in
On Thursday, 13 January 2022 at 11:57:41 UTC, Araq wrote:
But the time it takes depends on the number of threads it has
to stop and the amount of live memory of your heap. If it took
4ms regardless of these factors it wouldn't be bad, but that's
not how D's GC works...
Sadly fast scanning is
On Thursday, 13 January 2022 at 10:21:12 UTC, Stanislav Blinov
wrote:
TLDR: it's pointless to lament on irrelevant trivia. Time it!
Any counter-arguments from either side are pointless without
that.
"Time it" isn't really useful for someone starting on a project,
as it is too late when you
On Wednesday, 12 January 2022 at 20:48:39 UTC, forkit wrote:
Fear of GC is just a catch-all-phrase that serves no real
purpose, and provides no real insight into what programmers are
thinking.
"Fear of GC" is just a recurring _excuse_ for not fixing the most
outdated aspects of the
On Saturday, 8 January 2022 at 20:50:56 UTC, max haughton wrote:
Most other compilers have been able to do this for years.
Forever.
I have never used a C compiler that doesn't output assembly on
request. Pretty much a cultural requirement as C compilers used
to pipe asm through a separate
On Saturday, 6 November 2021 at 15:46:57 UTC, JN wrote:
This is much less of a strength than you think. For 90% of
cases, lack of metaprogramming is resolved by putting a Python
script in build step that autogenerates the necessary code.
Yes, I agree. For a single project metaprogramming has
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
That doesn't mean tracing GC is bad, I'm still skeptical that
arc + cycle detection is better than tracing in general for
true high level languages.
For truly high level languages garbage collection probably is the
best, if you design
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote:
My use case of writing GUI apps for desktop - presence of GC
does not matter for me at all. In fact its great for me.
Hopefully D will not stop covering these use cases.
Great, I am interested in highly interactive apps (games, sound
On Saturday, 5 June 2021 at 09:47:11 UTC, Imperatorn wrote:
I get your point, but I still think GC will remain mainly
because of the area D is trying to cover.
You mean the wait-for-everything-to-stop-scan-everything approach
will remain?
What is the area that D is trying to cover though?
On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:
Meanwhile kids, the future generation of developers, keeps
adopting the hardware and programming languages listed above,
D isn't useful for teaching kids programming. Wy too
complicated. Most Arduino users, who build useful
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:
You might be surprised, but it's actually not up to you what
topic fits or not.
This is the announce forum, so it is kinda misplaced, but we are
all contributing to this so... :)
Obviously GC is good for some things and not good at
On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:
D certainly has the power to do so but the question is if there
is any will power in this community. Nothing has happened for
almost 20 years.
I guess importC will make changes even more unlikely. Absorbing C
is nice, but it has the
On Friday, 4 June 2021 at 14:07:38 UTC, drug wrote:
I use GC when developing an algorithm to solve my problem.
After I has implemented the algorithm I can redesign it to
avoid GC (if needed). It works pretty nice in my case at least.
Because initially I concentrate on my domain problem and
On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote:
On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
GC won't go away tho. What might happen is more flexibility.
The GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational.
The most
On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
GC won't go away tho. What might happen is more flexibility.
The GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational.
You have to wait for all participating threads to be ready to
collect, so it
On Friday, 4 June 2021 at 00:39:41 UTC, IGotD- wrote:
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote:
Zim: the grammar is ugly.
Zim? Is that what they speak in Zimbabwe?
Zig.
On Monday, 19 April 2021 at 09:06:17 UTC, FeepingCreature wrote:
Right, I agree with all of this. I just think the way to get to
it is to first allow everything, and then in a second step pare
it down to something that does what people need while also
being monitorable. This is as "simple" as
On Monday, 19 April 2021 at 06:37:03 UTC, FeepingCreature wrote:
This is a social issue more than a technical one. The framework
can help, by limiting access to disk and URLs and allowing
tracing and hijacking, but ultimately you have to rely on code
to not do crazy things.
I think the
On Tuesday, 26 January 2021 at 16:05:03 UTC, Paul Backus wrote:
Well, the incorrect behavior is a liability whether we have an
issue for it in bugzilla or not. The issue itself is an asset.
IFF there is development process that ensure that old issues are
being reconsidered for every release.
On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote:
So don't look at the bug count as some kind of liability to rid
ourselves of by whatever means possible; rather, look at it as
a sign of life and the opportunity to grow.
Depends on the nature of the bug, doesn't it?
If the bug is
On Tuesday, 19 January 2021 at 09:33:26 UTC, Paolo Invernizzi
wrote:
On Tuesday, 19 January 2021 at 00:12:49 UTC, Max Haughton wrote:
The second category is a bit looser, as there are some things
I'd like to do that come under the community relations remit
that aren't as structured - e.g. I
On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote:
I plan to use dparse for the most part, not only to convert but
also to detect non bootstrapable code or missing features.
Ah, smart. I've been thinking about using an existing d-parser to
convert unit tests from D to my Dex syntax
On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote:
This is the last[1] occasion to speak about a programming
language initiatly made in D, as the bootstrap phase is very
near.
Interesting project! How did you move from D to Styx? (I assume
bootstrapping means a self hosting
On Thursday, 7 January 2021 at 13:03:54 UTC, Luhrel wrote:
I think that `int[$] a = [1, 2, 3]` is much more user-friendly.
```
auto a = [1,2,3].staticArray!ubyte
```
But what prevents you from writing your own library solution that
works like this?
auto ints = mkarray(1,2,3,4,5);
auto
On Wednesday, 6 January 2021 at 12:02:05 UTC, Basile B. wrote:
No. I agree. Do you imagine if this conversation was in the
offical DIP review.
E.g those two a**holes who troll the review process /s
LOL, people have their own frame of reference so the shorter the
DIP the more interpretations
On Wednesday, 6 January 2021 at 11:39:08 UTC, Basile B. wrote:
Hmm...
My take is that this proposal is auto with a constraint,
except it will also do implicit conversion.
yeah the split of DIP feedbacks and DIP discussions was clearly
not a bad thing ^^
Do you disagree?
On Wednesday, 6 January 2021 at 11:18:22 UTC, Basile B. wrote:
I thought about auto when reading the DIP too, but auto is more
used like a Type (although being a storage class ;) ). It's
never used to infer a value, i.e an expression. While I
understand what you mean this is unrelated. Dollar
On Wednesday, 6 January 2021 at 10:55:39 UTC, Ola Fosheim Grøstad
wrote:
int[_] = …
or
_[_] …
To expand on this with more examples, you might want to constrain
"auto" in various ways with pattern matching:
// ensure static array of something with length 4
_[4] v = f();
// ensure that I
On Wednesday, 6 January 2021 at 10:58:23 UTC, Basile B. wrote:
'$' is not an ident char, that's why that works
Yeah, but "$" means length in D. I think it would be valuable to
have more generic constraints than the DIP suggests so that it
can be useful in multiple contexts.
Would
I am in favour of more controlled type inference in general, but
perhaps this one is a bit specific. What if you defined "_" to
mean "deduce whatever should be in this spot", not only for
static arrays, but for all types?
Then you could do:
int[_] = …
or
_[_] …
etc
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 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 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 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 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 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 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 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 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 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 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: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 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: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: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 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 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 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
1 - 100 of 307 matches
Mail list logo
