[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #21 from Steven Schveighoffer  ---
To add to this, I think the use case being held as the example that shows why
this was done is:

a.d:
module a;

struct S {}
void foo() {}

void m(S s) {}

// uncomment to hijack!
// void bar() {}

b.d:
module b;

class Foo
{
   import a;
   S s;
}

c.d:
module c;
void bar() {}

d.d:
module d;
import b;
import c;

foo();

class Bar : Foo
{
   void x() {
 foo();
 bar();
 s.m();
   }  
}

So x calling foo calls local foo. That's fine, with new import rules, nothing
outside of d.d can change that. The fix is to avoid calling a.bar if it was
added at a later time.

But what about the prevention of Bar from seeing m? Surely, when we want to
include an S member, we want to include it's entire interface. Now if some
other module defines an m that accepts an S, then s.m means something different
in Bar than it does in Foo! This can't be the right solution, can it?

This seems like it was broken before, and is broken in a different way now.
It's impossible to tell what the original code "wanted" to do. But it seems
pretty clear to me that Foo has a certain view of what an S API looks like, and
it meant to forward that view to its subclasses.

I can at least document the change in my blog article, because even if this
decision is reversed, 2.071 is already out there.

--

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #20 from Steven Schveighoffer  ---
(In reply to Mathias Lang from comment #18)
> Feel free to reach out to me by email if not.

In the interest of keeping the discussion public, I'll just reply here.

> Now there is something special about 'mixin template' and 'class' /
> 'interface' declaration: they are the only remote (as in, outside of the
> module) symbol one can inherit it's scope from. 
> 
> But inheriting the imports leads to the same issues 10378 describe: you can
> end up in a situation where adding a symbol to module 'foo' which is
> 'protected import' of class 'A' will suddenly change which symbol is
> selected in subclass 'B : A'. However, if you have both imports at the same
> level, you'll get a conflict.

I think what you are saying is that a mixed in template could affect existing
*imports*, right? But an import can already do that! Ignoring imports with
mixins doesn't fix this problem.

The mixin could not hijack local symbols, right? I thought that was the larger
point -- you are referring to class/local symbols, or even module functions,
and suddenly that changes through a hijacked import.

I get that it's good to prevent hijacking as much as possible. But this doesn't
disallow hijacking to any further degree than is already disallowed. In other
words, preventing mixins from hijacking imported symbols doesn't remove the
problem, and just makes the language inconsistent.

> The only kind of hijacking I can think of ATM is when an import which is
> more nested than another one introduce an already-used symbol.
> 
> E.g. if this class used 'b.myFunc' before and a new library introduce
> 'd.myFunc':

Right, but this still exists. Why prevent it in the case of a mixin?

For example, d could public import x. x could define myFunc. This is pretty
much equivalent to the mixin case.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #19 from Ketmar Dark  ---
>But maybe your idea of registering on demand is worth considering even with 
>that
>update.
if you'll decide that it worth keeping, then just drop a note in 16298, i can
rewrite the patch to use CT reflection instead. if you don't want to create
your own patch from scratch, of course. ;-)

>Sorry about the strife!
no problems. ;-)

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #18 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #17)
> p.s. if it works, please, close my ER in issue 16298 then.

Sure. I personally hate the way std.encoding registers all the encodings, so
I'd like to fix that anyway (but by using compile-time reflection, not strings
and object.factory). But maybe your idea of registering on demand is worth
considering even with that update.

Sorry about the strife! Cycles in D suck. Hopefully we can make the whole thing
more pleasant.

--

[Issue 16282] Partial permutation/nextPermutation in std.algorithm

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16282

--- Comment #3 from greenify  ---
> It looks about how I had envisioned it, but I'm not really
jazzed about the idea of installing an entire mathematics package for a one-off
script I was expecting to take fifteen minutes.

Do you know about the new inline dub header? At least that's the tradeoff I am
taking at the moment.

#!/usr/bin/env dub
/+ dub.sdl:
name "foo"
dependency "mir" version="0.15.3"
+/

In any case I recommend making a bit of fuzz at the NG (forum.dlang.org) as
this thread isn't monitored by many people. D developers are actually quite
responsive to constructive feedback :)

> As for the reasoning, I just figured this was obvious?

Yes, when I needed it I was shocked too and thus wrote the small combinatorics
module :/

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #17 from Ketmar Dark  ---
p.s. if it works, please, close my ER in issue 16298 then.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #16 from Ketmar Dark  ---
how did you dare to make my great patch unnecessary?! ;-))

--

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #19 from det <2k...@gmx.net> ---
(In reply to Mathias Lang from comment #18)
> The rationale is that this behavior allowed symbol hijacking.
> 
> The behavior of the compiler was changed to perform 2 passes for symbol
> resolution, the first one on local symbol, the second one on imports.
> ...
> See https://issues.dlang.org/show_bug.cgi?id=10378 for the actual issue.

i think the problem steve and i have is that the communicated changes that came
with 2.071 are the following two
1) don't be able to use symbols that are not visible (which is of course
according to specs but was not enforced beforehand)
2) change in lookup sequence to prevent hijacking

(2) relates to your examples in c18 and
https://issues.dlang.org/show_bug.cgi?id=10378

however, the issue here WRT mixin templates is the following:
it is NOT just (2) at work, i.e. a change in lookup sequence - which would be
straightforward. but rather, whole module imports mixed in are completely
ignored. why such an enforcement? it seems overly excessive and restrictive as
just an application of (2) would have prevented hijacking.

and unlike the well communicated changes (1) and (2) this new behavior is NOT
supported by the current language specs and has so far not been officially
communicated anywhere.

when ppl's code fails (as happened to me), they search the specs, find nothing,
search the bug tracker/issues, find this very example of the problem, and see
it is marked as fixed - in contradiction to the issue being persistent. yes,
the changed subject gives a hint but i still favor a split into a 2 issues:
o this one being 'resolved invalid'
o a new 'see also' linked issue that is 'resolved fixed'
and of course official documentation/specs that reflect the changes in
behavior.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #15 from Steven Schveighoffer  ---
I'm going to have to take back what I said. I added back in the static ctors,
and there is no cycle, even with my patch that fixes cycle detection. It's
probably all the work on trimming out unnecessary imports that has helped this.

I'll "revert" what I did by moving the static ctors back into std.encoding.

--

[Issue 16282] Partial permutation/nextPermutation in std.algorithm

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16282

--- Comment #2 from Wyatt  ---
I guess it might?  It looks about how I had envisioned it, but I'm not really
jazzed about the idea of installing an entire mathematics package for a one-off
script I was expecting to take fifteen minutes.

As for the reasoning, I just figured this was obvious? I mean, there probably
isn't an introductory text on permutation that doesn't cover the constrained
case.

--

[Issue 13537] Unions may break immutability

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13537

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 13537] Unions may break immutability

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13537

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/09ed87c973fbcb777806506f7e05fbed30a3f355
fix Issue 13537 - Unions may break immutability

https://github.com/dlang/dmd/commit/72077372aec4aa77899885fc5cffbdbc5d289021
Merge pull request #5940 from WalterBright/fix13537

fix Issue 13537 - Unions may break immutability

--

[Issue 16299] New: Documentation for Phobos needs to warn about autodecoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16299

  Issue ID: 16299
   Summary: Documentation for Phobos needs to warn about
autodecoding
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: wyatt@gmail.com

Problem:
The anomalous effects of autodecoding for Phobos functions are _effectively_
undocumented.  This means an innocent user has no warning that something like
std.algorithm.iteration.permutations will fail on an array of char[] (a very
common built-in type).  This is bad.

Possible fixes:
- Add warnings (with text _and_ links) that using char[] is going to screw
users:
If using a char[] is going to break something, that should be mentioned in
the documentation for it.  There at least needs to be a generic warning that
stands out visually and links to further information on the autodecoding
problem and how to work around it.

- Add examples that show affected templates used on char[] and dchar[]:
Most of the examples are conscripted unit tests using integers.

- Have the compiler explain the actual problem:
Ugly? Maybe. Special casing is bad? Sure. But the current error is really
obtuse when you can do exactly what the example does only with a different type
and get "cannot deduce function from argument types".  That's way out of left
field.

- Make it actually work like it should:
Especially if the input is known at compile time, autodecoding shouldn't
even be a problem.  But even at runtime, this should just work without fuss. 
Users shouldn't have to hunt down the documentation for template constraints if
they're not writing range types of their own; we made them grey because most
people _can_ ignore them.

See Also: 
Comments on issue #16263

--

[Issue 15925] -transition=[check]imports ignores import declaration from mixin templates

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15925

--- Comment #17 from Steven Schveighoffer  ---
(In reply to Mathias Lang from comment #16)
> The details of the bug were wrong (it should be ignored unlike what I
> originally believed)

While this has your attention, can you point me at the rationale to why this is
so? See my earlier comment 14.

BTW, we shouldn't rename or repurpose bugs like this.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Jack Stouffer  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Severity|enhancement |regression

--- Comment #14 from Jack Stouffer  ---
Because this broke code I am raising this to a regression.

--

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16298

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #13 from Ketmar Dark  ---
did it: https://issues.dlang.org/show_bug.cgi?id=16298

--

[Issue 16298] New: [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16298

  Issue ID: 16298
   Summary: [ER] lazily register standard codecs from std.encoding
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

Created attachment 1604
  --> https://issues.dlang.org/attachment.cgi?id=1604=edit
lazily registers standard codecs

the attached patch seems to work ok with my system. it registers standard
codecs when on first call to `EncodingScheme.create()`, and it also exposes
`EncodingScheme.registerStandardCodecs()` function, which can be called to
manually register standard codecs if it is necessary in some other module ctor.

it is safe to call `EncodingScheme.registerStandardCodecs()` multiple times,
and from multiple threads.

this patch solves issue 16291 for the time being, until the proper fix for
cycle detection in module ctors isn't complete.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #12 from Steven Schveighoffer  ---
Ketmar, thanks for the patch. I think you should open a new bug report with it
so it doesn't get lost. I have to fix the phobosinit code anyway, which will
close this.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #11 from Ketmar Dark  ---
p.s. we probably can enumerate all std.encoding module symbols with CTFE
reflection instead, but i don't think that it makes huge difference here.
paying small fee at program startup looks better for me than paying this fee
each time we compiling the code that imports std.encoding. while CTFE time is
small in this case, i prefer it this way.

but if you think that we should use compile-time reflection instead, feel free
to say that, and i'll rework the patch. ;-)

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #10 from Ketmar Dark  ---
Created attachment 1603
  --> https://issues.dlang.org/attachment.cgi?id=1603=edit
lazy standard codec registration

the attached patch seems to work ok with my system. it registers standard
codecs when user is first trying to use `EncodingScheme.create()`, and it also
exposes `EncodingScheme.registerStandardCodecs()` function, which can be called
to manually register standard codecs if it is necessary in some other module
ctor.

it is safe to call `EncodingScheme.registerStandardCodecs()` multiple times,
and from multiple threads.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #9 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #8)
> yes, i know. but std.encoding seems to not import anything that may
> indirectly import it back, and it *seems* to not break anything for my
> system.

That's because you don't have proper cycle detection on your system :) I
manually verified the cycle did exist. I don't remember the exact cycle
modules.

Note that there really aren't any cycles in terms of std.encoding requiring
some other module ctor to work correctly, but the runtime doesn't do a proper
job of sorting the order of the ctors, and when that is fixed, it can't solve
the ordering.

My fix that I pushed was not right -- the dependency is lost, and now may
result in incorrect ordering still.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #8 from Ketmar Dark  ---
>I should tell you that cycle detection is currently broken
yes, i know. but std.encoding seems to not import anything that may indirectly
import it back, and it *seems* to not break anything for my system.

i'm not insisting on that solution, though. maybe we can use some kind of "lazy
initialization" scheme instead, by writing a weird hack: on the first call to
`EncodingScheme.create()` we can find std.encoding in module list, and register
every encoder it has. i think this *may* work (if linker will not throw away
"unused classes"). i probably will try to write such code to see if it will
work.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #7 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #4)
> for now, easy fix is to move that thing back to "std.encoding", as it seems
> to not conflict with anything now. and probably create a new issue that
> documents this behavior.

This would bring back the cycle that it fixed. I should tell you that cycle
detection is currently broken, see issue 16211. I was getting cycle errors with
the fix for that issue until this fix was in place.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Steven Schveighoffer  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|schvei...@yahoo.com

--- Comment #6 from Steven Schveighoffer  ---
Hm... I also realized just now that what I did is not correct. There's a chance
that some other static ctor depends on std.encoding registry having been set
up. But the link between encoding and phobosinit isn't there, so the ordering
will be wrong.

I'll fix this in a PR.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #5 from Ketmar Dark  ---
p.s. i think that vibe.d works 'cause it passes all it's files to dmd instead
of creating .a library. then dmd generating single object file with everything
necessary inside, including module ctors. but for .a libraries, dmd is writing
alot of object files (one per function, i believe) to allow smartlinking.

so passing all phobos .d files to dmd should work as expected, but using .a
isn't. and i believe that vibe.d will have the same issue if it will be
complied as .a library.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #4 from Ketmar Dark  ---
as nothing directly referring to module ctors, linker just doesn't know that it
should not optimize 'em away. maybe we can fix that by emiting some flag for .o
files, but i don't really know -- i never even read about dwarf object file
format, so i'm not sure if such flag exists.

that is, linker really does it's work here: if nothing directly using the
symbol from object file, that object file is not linked to the final binary.
tbh, i don't know how can we solve this: if we will mark all module ctors as
"include always" (if it's possible), we will have alot of unnecessary (and
probably unused) code linked to the final binary. it doesn't hurt much, but
still...

for now, easy fix is to move that thing back to "std.encoding", as it seems to
not conflict with anything now. and probably create a new issue that documents
this behavior.

maybe we can introduce some UDA to mark modules that should not be optimized
away by smartlinking, or something like that, 'cause i guess that similar
issues are very possible in the future, as phobos becomes more and more
complex, with complex interdependencies.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #2)
> aha. i see.
> 
> the thing is that std.internal.phobosinit is not imported from anywhere, so
> linker simply not including it in resulting executable!
> 

Well... That's weird.

I assumed module ctors would still be included, even if not imported. How the
hell does vibe.d work, where everything is set up in a module ctor?

> 
> i.e. we have to do "import std.internal.phobosinit;" in "std.encoding". but
> that defeats the purpose of moving the whole thing to separate module, i
> guess.

Yes, it does. I purposely removed all imports of phobosinit (was called
processinit, and std.process imported it) to avoid cycles.

> what was the idea behind moving that initialization to separate module? it
> seems that leaving it in std.encoding is not conflicting with anything: not
> one of phobos modules that imports "std.encoding" has module ctors.

There was a cycle between std.encoding and something else. The easiest thing to
do was to remove the constructors.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark  ---
it seems that at least for x86 GNU/Linux ctor is called if i'm using
libphobos2.so instead of libphobos2.a. i inserted printf there, and yes: with
static phobos ctor is skipped, but with .so phobos it is called.

i found this not with test, but in my own app, which mysteriously stopped
working when i linked it with static phobos.

--

[Issue 16297] New: Immutable data with statically-known initializer should be implicitly "static"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16297

  Issue ID: 16297
   Summary: Immutable data with statically-known initializer
should be implicitly "static"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

This came up during the review of https://github.com/dlang/dmd/pull/5938.
Consider:

int fun(ubyte[] b)
{
  immutable ubyte[4] d = [0x7F, 'E', 'L', 'F'];
  return b[] == d[];
}

int gun(ubyte[] b)
{
  static immutable ubyte[4] d = [0x7F, 'E', 'L', 'F'];
  return b[] == d[];
}

By http://goo.gl/mxaVKe, different code is generated for these functions;
namely, the immutable data in fun() is initialized with every call. An
optimization would allocate that data statically.

--

[Issue 16291] phobosinit fails to register encodings on individual tests

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16291

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

[Issue 16283] [Modules]

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16283

--- Comment #10 from Steven Schveighoffer  ---
(In reply to Sobirari Muhomori from comment #9)
> (In reply to Steven Schveighoffer from comment #8)
> > We put up with a lot of grammar inaccuracies that result in simply ignored
> > attributes. We can do better.
> 
> You mean you want to disallow this in grammar?
> ---
> pure:
> int n;
> ---

No, I mean that the grammar allows such things, and they are nonsense (but I
agree we shouldn't remove it).

Here, we have something that is plainly wrong in all cases, but the grammar
says it's allowed. We can't just say "well grammar can't do everything", when
clearly it can reflect this case.

--

[Issue 16296] std.math.exp should be CTFEable

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16296

greensunn...@gmail.com changed:

   What|Removed |Added

Summary|std.math.expo should run in |std.math.exp should be
   |CTFE|CTFEable

--

[Issue 16296] New: std.math.expo should run in CTFE

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16296

  Issue ID: 16296
   Summary: std.math.expo should run in CTFE
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

due to inline-asm it can't run at compile-time.

--

[Issue 16283] [Modules]

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16283

--- Comment #9 from Sobirari Muhomori  ---
(In reply to Steven Schveighoffer from comment #8)
> We put up with a lot of grammar inaccuracies that result in simply ignored
> attributes. We can do better.

You mean you want to disallow this in grammar?
---
pure:
int n;
---

--