Bug 12357 – Untyped string variable fails silently. No compiler warning given.

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2014-03-13T06:56:00Z
Last change time
2016-10-01T11:46:05Z
Keywords
pull
Assigned to
nobody
Creator
dev

Comments

Comment #0 by dev — 2014-03-13T06:56:55Z
Rather nasty bug that silently fails. Linux DMD64 D Compiler v2.065 import std.stdio; import std.array; import std.conv; import std.digest.crc; import std.random; class Foo { public string generateHash() { // The following variable is untyped // yet no compiler error is thrown. text = Random(unpredictableSeed).front.to!(string); // text is null here. return hexDigest!(CRC32)(text).array.to!(string); } } void main(string[] args) { auto foo = new Foo(); writefln("%s", foo.generateHash()); }
Comment #1 by andrej.mitrovich — 2014-03-13T07:10:58Z
As noted in the forums, this is related to property enforcement. It should be marked as a dupe of whatever the bug report was that has Kenji's pull request.
Comment #2 by destructionator — 2014-03-13T07:14:08Z
I'm not sure it all is to blame on the whole property thing... 1) The text function in the "setter" call returned a value that was unused. I think text in this case is a pure function, so that's a noop and potentially could be an error for that reason. 2) In the second case, it calls text with zero arguments, which i don't think ever makes sense. Perhaps we could change the signature to add an if(T.length) constraint to text. But yeah, the reason this is allowed at all is the loose property setter and optional parens features rather than a compiler bug.
Comment #3 by andrej.mitrovich — 2014-03-13T07:18:51Z
(In reply to comment #2) > I'm not sure it all is to blame on the whole property thing... > > 1) The text function in the "setter" call returned a value that was unused. I > think text in this case is a pure function, so that's a noop and potentially > could be an error for that reason. Yeah. > 2) In the second case, it calls text with zero arguments, which i don't think > ever makes sense. Perhaps we could change the signature to add an if(T.length) > constraint to text. I didn't even catch the second call. We could fix this right now. Although, would any generic code break? E.g.: void doStuff(T...)(T t) { call(t[0]); writeln(text(t[1..$])); // would end up failing if T.length is 1 } I fear the 'if(T.length)' would have to be used at the call site too. I'm not sure if this is a problem.
Comment #4 by monkeyworks12 — 2016-06-24T01:11:01Z
Comment #5 by github-bugzilla — 2016-06-30T21:22:27Z
Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/ac01da550f85db3f0e77eb40a5a3850578ca21ba Fix Issue 12357 - Deprecate calling text, wtext and dtext with 0 arguments https://github.com/dlang/phobos/commit/5b02e869979bc0dda4c880b9e2b15c429c87c0a7 Merge pull request #4460 from MetaLang/fix12357 Fix Issue 12357 - Deprecate calling text, wtext and dtext with 0 arguments
Comment #6 by github-bugzilla — 2016-10-01T11:46:05Z
Commits pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/ac01da550f85db3f0e77eb40a5a3850578ca21ba Fix Issue 12357 - Deprecate calling text, wtext and dtext with 0 arguments https://github.com/dlang/phobos/commit/5b02e869979bc0dda4c880b9e2b15c429c87c0a7 Merge pull request #4460 from MetaLang/fix12357