[Issue 13540] New: Meaningless alias declaration is accepted
https://issues.dlang.org/show_bug.cgi?id=13540 Issue ID: 13540 Summary: Meaningless alias declaration is accepted Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: k.hara...@gmail.com The alias declaration: alias int[] f(TemplateTypeParam)(int arg); is just treated as: alias int[] f(int arg); static assert(is(f* == int[] function(int)); and the redundant template parameter list is just ignored. --
[Issue 9748] Wrong scope of templated nested functions in static foreach
https://issues.dlang.org/show_bug.cgi?id=9748
Mathias LANG pro.mathias.l...@gmail.com changed:
What|Removed |Added
CC||pro.mathias.l...@gmail.com
--- Comment #2 from Mathias LANG pro.mathias.l...@gmail.com ---
Real world use case where I hit this bug:
import std.typetuple, std.traits;
struct UDAStruct {
string identifier;
}
class MyClass {
@(UDAStruct(p3), UDAStruct(P2), UDAStruct(p1))
void func(int p1, string p2, float p3) {}
}
template CmpIdentifier(UDAStruct uda, string pname) {
pragma(msg, Instantiated for: ~pname);
enum CmpIdentifier = (uda.identifier == pname);
}
unittest {
alias Func = MyClass.func;
enum ParamNames = ParameterIdentifierTuple!Func;
enum ParamAttr = __traits(getAttributes, Func);
foreach (attr; ParamAttr) {
alias Cmp(string s) = CmpIdentifier!(attr, s);
pragma(msg, Current attr is: ~attr.identifier);
static assert(anySatisfy!(Cmp, ParamNames));
}
}
void main() {}
Output:
Current attr is: p3
Instantiated for: p1
Instantiated for: p2
Instantiated for: p3
Current attr is: P2
Current attr is: p1
(From: http://forum.dlang.org/thread/ojmpcrxrobjoqfrks...@forum.dlang.org )
--
[Issue 13532] std.regex performance (enums; regex vs ctRegex)
https://issues.dlang.org/show_bug.cgi?id=13532 --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com --- (In reply to Vladimir Panteleev from comment #0) The first surprise for me was that declaring a regex object (either Regex or StaticRegex) with enum was so much slower. It makes sense now that I think about it: creating a struct literal inside a loop will be more expensive than referencing one already residing somewhere in memory. Perhaps it might be worth mentioning in the documentation to avoid using enum with compiled regexes. It's a common anti-pattern, it's the same issue with array literals, it's the same issue with anything that takes some time to compute or allocates. regex function call does both. It's worth adding a note though, fell free t create a pull. I'm not sure I'll get to it soon. (In reply to Vladimir Panteleev from comment #2) Well, it's slower for this particular case, not necessarily in general. CCing Dmitry. That's right. Problem is simple backtracking engine of CTFE version which is an unfortunate historical point as I'd pick the other engine of the two if I could go back in time. (In reply to hsteoh from comment #1) ctRegex is slower than regular regex?! Whoa. That just sounds completely wrong. What's the cause of this slowdown? I thought the whole point of ctRegex is to outperform runtime regex by making use of compile-time optimization. Whatever happened to that?? If this is the case, we might as well throw ctRegex away. I'm fully aware of this. Unfortunately adding yet another engine (C-T robust engine) is increasingly a maintenace disaster. Consider also that working on compile-time generated regex is a nightmare of ~5-10 minutes to run all tests and constant out of memory conditions. Duplicating the amount of work done at CTFE is something DMD CAN'T handle at the moment. Another problem is regex accumulated a lot of technical debt, and needs a serious amount of refactoring before pling up more stuff. Then with modular design (the one I roughly outlined in my talk) we can put more and more components into it. Sadly all of this goes very slooowly. --
[Issue 13541] New: std.windows.syserror.sysErrorString() should be nothrow
https://issues.dlang.org/show_bug.cgi?id=13541
Issue ID: 13541
Summary: std.windows.syserror.sysErrorString() should be
nothrow
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: major
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
It should be nothrow because it is called by constructors like FileException,
which are themselves exceptions. Exceptions should be buildable without having
double fault exceptions happening.
Digging into sysErrorString() there's this:
if(length == 0)
{
throw new Exception(
failed getting error string for WinAPI error code: ~
sysErrorString(GetLastError()));
}
This should be an assert because:
1. sysErrorString()'s argument should ONLY be values returned by Windows APIs
like GetLastError(), and so this should always succeed.
2. recursively calling sysErrorString() with the SAME value will cause a stack
overflow crash, not any usable exception.
Following this fix, sysErrorString() should be marked as 'nothrow'.
--
[Issue 13542] New: std.file.FileException has GetLastError() as a default argument
https://issues.dlang.org/show_bug.cgi?id=13542 Issue ID: 13542 Summary: std.file.FileException has GetLastError() as a default argument Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com This has problems: 1. GetLastError() is not the same as errno, although D also has errno. So there's confusion and wrong documentation about the arguments. 2. FileException is never called by anyone other than std.file, so the constructor should be marked private. 3. The call to GetLastError() should be moved into the constructor body, in order to reduce bloat (i.e. having code for it generated over and over at the call site). --
[Issue 13543] New: std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 Issue ID: 13543 Summary: std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com I take exception (!) to this notion. As a computer user (not a programmer) what would one think about error messages from an application that printed file and line of something internal to the app's source code? WTF, right? FileException is being confused here with being a programmer debugging tool. It is NOT. Exceptions are not for debugging programming errors. They're for reporting on input errors. They're being confused with asserts here. --
[Issue 13544] New: calls to std.file.FileException are idup-ing their string arguments
https://issues.dlang.org/show_bug.cgi?id=13544 Issue ID: 13544 Summary: calls to std.file.FileException are idup-ing their string arguments Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com The signature for functions like std.file.copy() takes in char[] so it can be called with both mutable and immutable strings. If an exception gets thrown, the conservative assumption is that the source may get changed so the string is duplicated. The problem, again, is bloat. The solution is to add two overloads for FileException, one taking string and one taking const(char)[]. --
[Issue 13545] New: Functions in std.file should take const(char)[] parameters, not char[] parameters
https://issues.dlang.org/show_bug.cgi?id=13545 Issue ID: 13545 Summary: Functions in std.file should take const(char)[] parameters, not char[] parameters Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com They shouldn't be modifying their called arguments. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc --- I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation. --
[Issue 13546] New: std.functional.not for arrays too
https://issues.dlang.org/show_bug.cgi?id=13546
Issue ID: 13546
Summary: std.functional.not for arrays too
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
I suggest std.functional.not to accept arrays too (and associative arrays) and
not just functions:
void main() {
import std.stdio: writeln;
import std.algorithm: filter;
import std.functional: not;
auto keys = [1, 2, 1, 1, 1, 2, 3];
auto arr = [true, true, false, true];
auto r1 = keys.filter!(k = !arr[k]);
r1.writeln; // Output: [2, 2]
auto r2 = keys.filter!(not!arr);
r2.writeln;
}
--
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- (In reply to bearophile_hugs from comment #1) I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation. Once again, Exceptions are NOT for debugging user code. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #3 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #2) (In reply to bearophile_hugs from comment #1) I guess a FileException should give the line number of the *user* code where he/she has performed a failed file operation. Once again, Exceptions are NOT for debugging user code. I don't agree. If I open a file, and the opening fails, I'd like the exception to tell me what damned line of my code has tried to open that file. Exceptions are useful to debug user code. --
[Issue 13544] calls to std.file.FileException are idup-ing their string arguments
https://issues.dlang.org/show_bug.cgi?id=13544 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- A better solution is to use to!string, which is a no-op if the source and destination types are identical. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #4 from Walter Bright bugzi...@digitalmars.com --- (In reply to bearophile_hugs from comment #3) (In reply to Walter Bright from comment #2) Once again, Exceptions are NOT for debugging user code. I don't agree. If I open a file, and the opening fails, I'd like the exception to tell me what damned line of my code has tried to open that file. Exceptions are useful to debug user code. This is a serious misuse of Exceptions. What do your customers think when your apps are showing them file/line pointing to your internal source code when a file doesn't exist? I've never even heard of an app that would assault users with such error messages, except for D apps. The construct to debug code is assert, not throw. Cue my usual rant about confusion between what is a programming logic error and what is an input/environmental error, and the conflation of the methods for dealing with them. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543
--- Comment #5 from bearophile_h...@eml.cc ---
(In reply to bearophile_hugs from comment #3)
If I open a file, and the opening fails, I'd like the
exception to tell me what damned line of my code has tried to open that
file.
- - - - - - - - - - - - - - -
A Python script (both files are missing):
f1 = open(some_file1.txt)
f2 = open(some_file2.txt)
Gives information that helps to locate what's the line that has tried to open
the missing file:
Traceback (most recent call last):
File ...\test.py, line 1, in module
f1 = open(some_file1.txt)
IOError: [Errno 2] No such file or directory: 'some_file1.txt'
- - - - - - - - - - - - - - -
A similar D program gives line number inside the library code, but I'd like an
exception that tells me that the problem is in test.d at line 3:
void main() {
import std.stdio;
auto f1 = File(some_file1.txt);
auto f2 = File(some_file2.txt);
}
std.exception.ErrnoException@std\stdio.d(364): Cannot open file
`some_file1.txt' in mode `rb' (No such file or directory)
0x0040447B in @safe shared(core.stdc.stdio._iobuf)*
std.exception.__T12errnoEnforceTPOS4core4stdc5stdio6_iobufVAyaa11_7374645c737464696f2e64Vki364Z.errnoEnforce(shared(core.stdc.stdio._iobuf)*,
lazy immutable(char)[])
...
- - - - - - - - - - - - - - -
--
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #6 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #4) This is a serious misuse of Exceptions. What do your customers think when your apps are showing them file/line pointing to your internal source code when a file doesn't exist? It's a basic information, better than no information at all. If my app tells me a file is missing then maybe I can find it. But see below. I've never even heard of an app that would assault users with such error messages, except for D apps. The construct to debug code is assert, not throw. Adding the line number of the user code that has caused the IO exception is handy to fix little script-like D programs. A IO exception is meant to be caught by your large serious programs, it's never meant to be shown to users. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #7 from Walter Bright bugzi...@digitalmars.com --- (In reply to bearophile_hugs from comment #6) A IO exception is meant to be caught by your large serious programs, it's never meant to be shown to users. 1. You are trying to use exceptions to debug the program. This is utterly wrong. 2. Exceptions are meant to provide information to the user of the app, not the programmer of the app. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #8 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #7) 1. You are trying to use exceptions to debug the program. This is utterly wrong. It's what millions of people are doing every day in Python, Ruby, etc. If you are writing a 50 lines long script program that loads some files, you are thankful when the exception tells you what line of your code has opened a missing file. In such small D programs you don't want to add assert(isOpen(...) isWriteable(...)) and even if you do that, there are other problems, like asserts and file ops getting out of sync, file state changing between the assert and the file operation, etc. 2. Exceptions are meant to provide information to the user of the app, not the programmer of the app. As an user of the app, the app should tell me that a file is missing with a nice pop up window, or better, not with exceptions. But not all D programs are large, and giving the line number in the exception message is a first basic information when the code has bugs or when the D program is not an app, but a little script-like (and I write many such tiny D programs). --
[Issue 13547] New: D is a fully garbage collected language
https://issues.dlang.org/show_bug.cgi?id=13547 Issue ID: 13547 Summary: D is a fully garbage collected language Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: critical Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: peter.alexander...@gmail.com http://dlang.org/garbage.html This page starts with D is a fully garbage collected language. This is a bad message for people looking at D's memory management offering. The page should state, very clearly, in the first sentence that D supports more than garbage collection, and provide examples and links. This is scaring people away: https://twitter.com/bitshifternz/status/515998608009601024 (I know we have other pages that describe our manual management solutions, but someone idly Googling D garbage collection may land here and discard D immediately without further investigation). --
[Issue 13548] New: wrong FP comparison
https://issues.dlang.org/show_bug.cgi?id=13548
Issue ID: 13548
Summary: wrong FP comparison
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: blocker
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
Win64 FreeBSD32 are affected.
Tester:
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1repoid=3pullid=2548
PR:
https://github.com/D-Programming-Language/phobos/pull/2548#issuecomment-57064711
unittest
{
import std.stdio;
import std.string;
assert(isIdentical(abs(-0.0L), 0.0L));
assert(isNaN(abs(real.nan)));
assert(abs(-real.infinity) == real.infinity);
assert(abs(-3.2Li) == 3.2L);
assert(abs(71.6Li) == 71.6L);
assert(abs(-56) == 56);
assert(abs(2321312L) == 2321312L);
assert(abs(creal (-1+1i)) == sqrt(2.0L));
cdouble c = -1+1i;
assert(sqrt(c.re*c.re+c.im*c.im) == sqrt(2.0));
double ad, bd, cd;
ad = sqrt(2.0);
bd = hypot(c.re, c.im);
cd = sqrt(2.0);
assert(ad == cd, FP fail); //---FAILS SQRT(2) !=
SQRT(2)
assert(ad == bd, format(sqrt(2.0) = %.*a, hypot(c.re, c.im) = %.*a, 25,
ad, 25, bd));
assert(hypot(c.re, c.im) == sqrt(2.0), format(sqrt(2.0) = %.*a,
hypot(c.re, c.im) = %.*a, 20, sqrt(2.0), 20, hypot(c.re, c.im)));
assert(abs(c) == sqrt(2.0));
assert(abs(cdouble(-1+1i)) == sqrt(2.0 ));
assert(abs(cfloat (-1+1i)) == sqrt(2.0f));
}
--
[Issue 13548] wrong FP comparison
https://issues.dlang.org/show_bug.cgi?id=13548 Илья Ярошенко ilyayaroshe...@gmail.com changed: What|Removed |Added Keywords||wrong-code --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #9 from Walter Bright bugzi...@digitalmars.com --- (In reply to bearophile_hugs from comment #8) It's what millions of people are doing every day in Python, Ruby, etc. If you are writing a 50 lines long script program that loads some files, you are thankful when the exception tells you what line of your code has opened a missing file. I doubt I'd have trouble locating a 'throw' statement in a 50 line program. I don't believe you would, either. In such small D programs you don't want to add assert(isOpen(...) isWriteable(...)) and even if you do that, there are other problems, like asserts and file ops getting out of sync, file state changing between the assert and the file operation, etc. Sorry, I think this is rubbish. (You also do not want to catch Exception messages just to filter out the file/line to then present the message to the user.) 2. Exceptions are meant to provide information to the user of the app, not the programmer of the app. As an user of the app, the app should tell me that a file is missing with a nice pop up window, Console apps don't need to that, and it's pretty easy for a gui app to provide a top level handler that pops up a window. or better, not with exceptions. But not all D programs are large, and giving the line number in the exception message is a first basic information when the code has bugs Again, Exceptions are NOT A DEBUGGING TOOL and should NOT BE THROWN WHEN BUGS ARE DETECTED. Use asserts for that. Asserts are designed for that, and are pretty good at it. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #10 from Walter Bright bugzi...@digitalmars.com --- To put things more clearly, Exceptions are for: 1. so code can recover cleanly from input/environmental errors 2. if (1) is not possible, report the error to the app user in a manner that is sensible to the app user They are NOT for: 1. so the code can recover from internal programming bugs 2. reporting internal programming bugs to the app user --
[Issue 5007] @outer() attribute
https://issues.dlang.org/show_bug.cgi?id=5007 --- Comment #8 from bearophile_h...@eml.cc --- Walter Bright has commented on @outer(): I suggest using 'pure' and passing the globals you actually need as ref parameters. This is what I usually do in D, but it has some small disadvantages: - It increases the number of function arguments (they are 8 bytes each), increasing the size of the function, adding some stack management instructions. This slows the function a little, if the function is performance-critical. - Sometimes you can't use pure, for various reasons, like Phobos functions not yet pure, I/O action in your function, or other causes. - If your pure function foo receives two global argument as out and ref, the function bar that calls it needs to access to global variables or it too needs those two ref/out arguments. The current design of @outer() is not transitive, so only foo needs to state what global variables are in/out/inout. - @outer is more DRY, because you don't need to specify the type of the global variable received by ref, you just need to know its name. - With @outer you can tighten some old code, without changing the signature of a function. If you have an old D module (or a C function converted to C) you often can't (or you don't want) to change the function signature to add the global arguments passed by ref. With @outer() the function signature doesn't change, so you can improve your legacy code. It allows a simpler refactoring of code. More notes: - SPARK language has added a feature similar to @outer, but more verbose. See comment 5. - @outer() is optional and it's fiddly because not it's not meant for small D script-like programs, it's meant as a help for medium-integrity D programs (where you may think about using Ada language instead). --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #9) I doubt I'd have trouble locating a 'throw' statement in a 50 line program. I don't believe you would, either. Often there is no throw statement in the user code. See my answer in the newsgroup. Use asserts for that. Asserts are designed for that, and are pretty good at it. Have you seen asserts used to pre-test I/O actions in D script-like programs? I've never seen them in the wild. Large programs catch exceptions and offer meaningful error messages, windows, etc. And script-like programs just show the exception and stack trace. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||e...@gnuk.net --- Comment #12 from Brad Anderson e...@gnuk.net --- Generally speaking, the __FILE__/__LINE__ trick sounds like a perfect example of something you put in a Debug build and leave out of a Release build. It can be genuinely useful during development while the program's logic is still being hammered out but it's often not useful or desired to show this information to end users. --
[Issue 13482] std.algorithm.podSort
https://issues.dlang.org/show_bug.cgi?id=13482 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- We might want to consider putting this in druntime for sorting native arrays. --
[Issue 13543] std.file.FileException has useless __FILE__ and __LINE__ arguments tacked on
https://issues.dlang.org/show_bug.cgi?id=13543 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #13 from Ketmar Dark ket...@ketmar.no-ip.org --- that's why i HATE release builds. if release build crashes, it's a whole lot of hell to extract any useful info from the crash to fill bugreport. the whole thing with release builds should die. program must not crash. period. but IF it crashed, it must spit out ALOT of info, line numbers, backtraces, various internal states, and so on. so developer will NEVER need to ask to run thing debug build please, and try to reproduce the bug, 'cause i can't see where that message comes from and why. it's a PITA to ask users to do something like that. --
[Issue 13541] std.windows.syserror.sysErrorString() should be nothrow
https://issues.dlang.org/show_bug.cgi?id=13541 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #1 from Marco Leise marco.le...@gmx.de --- That recursion is really bad. :p 1. sysErrorString()'s argument should ONLY be values returned by Windows APIs like GetLastError(), and so this should always succeed. It should, yes. And that's surely Microsofts stance as well. Yet they state that 0 is returned on error, so if this was my code I would at least handle that case and print some generic English message like Failed to retrieve WinAPI error message for code 0x123456 instead of an empty string. --
[Issue 13541] std.windows.syserror.sysErrorString() should be nothrow
https://issues.dlang.org/show_bug.cgi?id=13541 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- sysErrorString should be replaced with the newly-added wenforce wherever applicable. Some code in Phobos (std.mmfile at least) also incorrectly uses/used errnoEnforce when the error code was stored in GetLastError, not errno. --
[Issue 13542] std.file.FileException has GetLastError() as a default argument
https://issues.dlang.org/show_bug.cgi?id=13542 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Per my comment in https://issues.dlang.org/show_bug.cgi?id=13541#c2 , we should look into replacing uses of FileException / GetLastError with wenforce. --
[Issue 13544] calls to std.file.FileException are idup-ing their string arguments
https://issues.dlang.org/show_bug.cgi?id=13544 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Walter Bright from comment #0) The signature for functions like std.file.copy() takes in char[] so it can be called with both mutable and immutable strings. If an exception gets thrown, the conservative assumption is that the source may get changed so the string is duplicated. The problem, again, is bloat. The solution is to add two overloads for FileException, one taking string and one taking const(char)[]. Doesn't that mean that we'd also need to add overloads to std.file.copy (and many other std.file functions)? (In reply to hsteoh from comment #1) A better solution is to use to!string, which is a no-op if the source and destination types are identical. That won't work for in char[], will it? It would only work by making the constructor templated. --
[Issue 13549] New: Local functions don't take outer function attributes
https://issues.dlang.org/show_bug.cgi?id=13549
Issue ID: 13549
Summary: Local functions don't take outer function attributes
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
void f() pure nothrow @nogc
{
static void localFunc()
{
}
localFunc();
}
Complains because localFunc is not @nogc or nothrow.
Doesn't complain about pure though.
My feeling is that the attributes should apply to everything in the scope that
they attribute?
--
