[Issue 24004] UFCS is not uniform/universal (enough)
https://issues.dlang.org/show_bug.cgi?id=24004
--- Comment #3 from RazvanN ---
(In reply to Bolpat from comment #2)
> It has nothing to do with visibility. `private` non-members won’t work, same
> as private member functions don’t work.
>
Actually it does, since some functions become visible whereas in the past they
weren't.
> This is already solved: The same problem exists when importing a module (as
> a whole) and having a local symbol with the same name. It’s two different
> overload sets (when there’s a match in both of them, it’s an error).
>
Note that this is not true: if a local symbol matches, the imports are no
longer searched, irrespective if the call is correct or not.
Anyway, I was referring to the situation where the symbol in the same module
does not match, but the one in the imported module does. Right now, if you have
module a that defines mem and import module b in its entirety and b also
defines mem, assuming you are calling mem so that b.mem matches but a.mem does
not you would get an error saying that a.mem cannot be called. With your
proposition, if you import a symbol from b, b.mem would become available via
UFCS.
> > Of course, this can be solved by adding some extra priority rules,
> > but this is just one example.
>
> The rules already exist.
No, as pointed out by my previous point they don't. You would have to define
the priority or at least see if the overload sets are merged or not.
>
> > There are probably other cases and each of these require extra logic
> > to treat them. Bottom line, I don't think that the extra complexity
> > is worth it to add such a feature for which I don't see any big benefit;
>
> The benefit is that UFCS can be used in templates. This *is* a big benefit.
>
What do you mean? UFCS can already be used with templates:
```
void fun(T)(T a) {}
void main()
{
2.fun();
}
```
I'm probably misunderstanding your point, but as I see it, the proposal just
wants to make some symbols visible if those are used via UFCS, I don't see how
templates are affected by this. If you are using a type and a function that
works on a type, just import them both. If you forget to import the function
that is used on the type, ideally a template constraint will catch that:
```
void fun(T)(T a)
if (__traits(compiles, a.mem()))
{
a.mem();
}
```
It's up to the user of the templated function to provide whatever context is
needed.
> > simply importing whatever function you want to use is a much
> > cleaner approach
>
> I argued why that cannot be done “simply” in templates. You need some
> non-trivial metaprogramming to extract the module of a type to then import
> it.
>
Yes, but I would argue that this is bad design. The implementer of the template
should make sure that the context is provided via template constraints. The
user of the template should provide the context.
> > and keeps you on the safe side given that people rarely encapsulate
> > things at the module level in a structured manner.
> > I mean, it would be really weird if you had a function that is not
> > specifically imported but used via UFCS because some other
> > functionality is imported in the module;
>
> I don’t really get it. A UFCS call is syntactically indistinguishable to a
> member function call; I have no idea how one looks at `obj.mem` and think
> “Where did `mem` come from?” because it could be a member function of the
> type. If it happens to be a non-member of the same module the type comes
> from, what’s the deal?
>
> I’m not suggesting that because an expression of type `T` is somewhere in
> your function that is equivalent to importing the module `T` is in. I’m only
> suggesting that `obj.mem` should be able to resolve to a non-member function
> inside the module `typeof(obj)` is in.
>
I understand, I just don't see the benefit of implementing this when you can
simply import the symbol if you need it. I don't see it as a convenience
feature, rather than a special case of UFCS that you need to explain to
newcomers. Right now, the explanation is trivial: "If you use a selective
import, you essentially import the designated symbol". With this proposal, this
becomes: "If you selectively import a symbol, you have access to that symbol
and to any other function (or just to functions that take a parameter of type
typeof(symbol) as the first parameter?) provided that the function is called
via UFCS". To me, that's justs special casing that uglifies the language for a
benefit that is easily obtainable with the current semantics.
> Via template type parameters (or alias parameters), you can have access to a
> type without importing anything. If you think of modules as the units of
> implementation, you now have partial access to the implementation.
> Because of UFCS, the question whether `obj.mem` calls a member function or a
> non-member function of `typeof(obj)`’s module is an implementation detail
> when
[Issue 12990] utf8 string not read/written to windows console
https://issues.dlang.org/show_bug.cgi?id=12990 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #23 from Walter Bright --- (In reply to Sum Proxy from comment #22) > SetConsoleCP(1200); 1200utf-16 Unicode UTF-16, little endian byte order (BMP of ISO 10646); available only to managed applications https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- It works with -m32 (the 32 bit OMF output) --
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761
--- Comment #3 from Walter Bright ---
This C program works with 64 bit Windows VC:
-
#include
#include
#include
void main()
{
fwprintf(stdout, L"Helláá LDC\n");
fflush(stdout);
}
--
So there's definitely something wrong with the Microsoft version code in
std.stdio.
This is on Windows 7.
--
[Issue 15761] Windows wide character console output broken with MS runtime
https://issues.dlang.org/show_bug.cgi?id=15761 --- Comment #4 from Walter Bright --- That program also works with Digital Mars C. --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 --- Comment #10 from Puneet Goel --- I think it is a bug (or maybe I should call it unexpected compiler behavior) at a more fundamental level. Consider how both clang and gcc treat literal suffix errors differently compared to Dlang: $ cat /tmp/test.d ulong test = 44LUNG; $ ldc2 /tmp/test.d /tmp/test.d(1): Error: semicolon expected following auto declaration, not `NG` /tmp/test.d(1): Error: no identifier for declarator `NG` $ cat /tmp/test.c int long unsigned test = 44LUNG; $ gcc /tmp/test.c /tmp/test.c:1:26: error: invalid suffix "LUNG" on integer constant 1 | int long unsigned test = 44LUNG; | ^~ $ clang /tmp/test.c /tmp/test.c:1:28: error: invalid suffix 'LUNG' on integer constant int long unsigned test = 44LUNG; ^ 1 error generated. --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 --- Comment #11 from Puneet Goel --- Should I reopen this error, or file another bug for unexpected/wrong literal suffix parsing? --
[Issue 11943] Emit warning for default initialized pointers
https://issues.dlang.org/show_bug.cgi?id=11943 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WONTFIX --
[Issue 12115] Segfault in FormatSpec.fillUp
https://issues.dlang.org/show_bug.cgi?id=12115 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |MOVED --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||dlang-bugzilla@thecybershad ||ow.net Resolution|--- |WORKSFORME --
[Issue 18763] Segfault in garbage collector
https://issues.dlang.org/show_bug.cgi?id=18763 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||dlang-bugzilla@thecybershad ||ow.net Resolution|--- |INVALID --- Comment #3 from Vladimir Panteleev --- This bug is unreproducible as it is missing sndfile.d and the mentioned oscillofun.flac. --
[Issue 24009] New: The garbage collector tries to allocate memory while the program is out of memory
https://issues.dlang.org/show_bug.cgi?id=24009 Issue ID: 24009 Summary: The garbage collector tries to allocate memory while the program is out of memory Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P3 Component: druntime Assignee: nob...@puremagic.com Reporter: dlang-bugzi...@thecybershadow.net - When the program runs out of memory, the runtime starts a GC cycle. - While the GC is running, the program is still out of memory, so requests for more memory from the OS will fail. - Therefore, it should not request more memory from the OS. - The GC requests more memory from the OS while it is running. - Therefore, the GC may cause the program to crash when it runs out of memory. Unfortunately I do not have a standalone reproducer, but here is a stack trace which illustrates the problem: #0 0x559438b8 in onOutOfMemoryErrorNoGC () #1 0x5593ed4b in core.internal.gc.impl.conservative.gc.Gcx.ToScanStack!(void*).ToScanStack.grow() () #2 0x55939957 in core.internal.gc.impl.conservative.gc.Gcx.collectRoots(void*, void*) () #3 0x559426a0 in core.thread.threadbase.thread_scanAll(scope void(void*, void*) nothrow delegate).__lambda2!(core.thread.threadbase.ScanType, void*, void*).__lambda2(core.thread.threadbase.ScanType, void*, void*) () #4 0x559472dc in core.thread.threadbase.scanAllTypeImpl(scope void(core.thread.threadbase.ScanType, void*, void*) nothrow delegate, void*) () #5 0x55947219 in core.thread.threadbase.thread_scanAllType(scope void(core.thread.threadbase.ScanType, void*, void*) nothrow delegate).__lambda2!(void*).__lambda2(void*) () #6 0x559426e0 in core.thread.osthread.callWithStackShell(scope void(void*) nothrow delegate) () #7 0x559471ee in thread_scanAllType () #8 0x55942666 in thread_scanAll () #9 0x55939a46 in core.internal.gc.impl.conservative.gc.Gcx.collectAllRoots(bool) () #10 0x5593bb92 in core.internal.gc.impl.conservative.gc.Gcx.markParallel(bool) () #11 0x5593b1e0 in core.internal.gc.impl.conservative.gc.Gcx.fullcollect(bool, bool, bool) () #12 0x55939269 in core.internal.gc.impl.conservative.gc.Gcx.smallAlloc(ulong, ref ulong, uint, const(TypeInfo)) () #13 0x5593f235 in core.internal.gc.impl.conservative.gc.ConservativeGC.runLocked!(core.internal.gc.impl.conservative.gc.ConservativeGC.mallocNoSync(ulong, uint, ref ulong, const(TypeInfo)), core.internal.gc.impl.conservative.gc.mallocTime, core.internal.gc.impl.conservative.gc.numMallocs, ulong, uint, ulong, const(TypeInfo)).runLocked(ref ulong, ref uint, ref ulong, ref const(TypeInfo)) () #14 0x55936cce in core.internal.gc.impl.conservative.gc.ConservativeGC.qalloc(ulong, uint, scope const(TypeInfo)) () #15 0x558c4ba3 in gc_qalloc () #16 0x5590e7fa in rt.lifetime.__arrayAlloc(ulong, ref core.memory.BlkInfo_, scope const(TypeInfo), const(TypeInfo)) () #17 0x558cc92e in _d_arrayappendcTX () #18 0x558cc0e9 in _d_arrayappendT () --
[Issue 23997] isClose(1, -double.infinity) returns true
https://issues.dlang.org/show_bug.cgi?id=23997 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8767 "Fix Issue 23997 - isClose(1, -double.infinity) returns true" was merged into master: - 9d1eada9b21b19578c6a71d9338a2ff93c905c9a by Vladimir Panteleev: Fix Issue 23997 - isClose(1, -double.infinity) returns true https://github.com/dlang/phobos/pull/8767 --
[Issue 23999] literal suffixes dont mix well with template instantiations
https://issues.dlang.org/show_bug.cgi?id=23999 mhh changed: What|Removed |Added CC||maxha...@gmail.com --- Comment #12 from mhh --- Why is this impossible to express? You can write a new rule to match it and then mark it illegal if nothing else. (That and the grammar is not the whole). I think it's worth banning this, C does for example. --
[Issue 24010] Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 24010] New: Destructor called before end of scope for tuples
https://issues.dlang.org/show_bug.cgi?id=24010
Issue ID: 24010
Summary: Destructor called before end of scope for tuples
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
Testcase:
```
alias AliasSeq(TList...) = TList;
import core.stdc.stdio;
int i = 0;
struct A {
~this() {
printf("~this\n");
i *= 2;
}
}
void main() {
{
AliasSeq!(A, A) params;
printf("statement\n");
i = 1;
}
printf("%d\n", i);
assert(i == 4);
}
```
The assertion fails.
Looking at the printout:
```
~this
~this
statement
1
```
you can see that the dtors are called before the statement `i = 1;`, instead of
at the end of the scope.
--
[Issue 24004] UFCS is not uniform/universal (enough)
https://issues.dlang.org/show_bug.cgi?id=24004 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- Thank you for the interesting proposal. It does have some merit, but I have reservations. In particular, what symbols get found and do not get found in a lookup has been the topic of several very heated debates. People have very different ideas about what is "intuitive" behavior and what isn't. For example, when and how local imports are searched. Everybody thinks their scheme is obvious and the others are demented. Then, we went and implemented "alias this" without thoroughly understanding what it means. And now we're stuck with some odd behaviors when different lookup schemes intersect. We can't fix it because too much existing code has settled into relying on its current behavior. People do not have a clear idea how things are looked up, much like in C++ nobody can explain how the overload rules work. Not even me, and I implemented them correctly. What people do is try random things until the overload they wanted is selected. We are already well down that path. This makes me very trepidatious about adding new overloading behaviors. Note that the proposed behavior may break existing code, and since people likely already just tried things until it worked, they may be quite baffled as to how to fix their code. So I'm reluctantly going to say no, unless some really strong, very compelling use case comes to the fore. I do appreciate your efforts, though. Proposals like yours are what makes developing new programming paradigms fun! Thank you. --
[Issue 23976] std.range.slide fails in dmd-2.104.0
https://issues.dlang.org/show_bug.cgi?id=23976 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @FeepingCreature created dlang/phobos pull request #8773 "Fix issue 23976: std.range.slide fails in dmd-2.104.0" fixing this issue: - Fix issue 23976: std.range.slide fails in dmd-2.104.0 I think possibly `hasShownPartialBefore` is just simply wrongly named in the `withPartial` branch. https://github.com/dlang/phobos/pull/8773 --
