Re: [Issue 8285] Error passing CTFE-generated string slice to template value parameter
On Tuesday, 26 June 2012 at 16:27:29 UTC, kenji hara wrote:
Direct replying to this news group/mailing list is no meaning.
You must post these test case from the form in bugzilla.
http://d.puremagic.com/issues/show_bug.cgi?id=8285
Kenji hara
2012/6/25 Max Samukha maxsamu...@gmail.com:
Another test case. The error is different but the root cause
must be the
same.
string bar()
{
string s = ab;
return s[0..$];
}
template T1()
{
enum T1 = bar()[0..$]; // error
}
string baz()
{
return T1!();
}
string foo(string s)
{
return s;
}
static assert(foo(baz()) == ab);
void main()
{
}
Error: variable __dollar cannot be read at compile time
For some brain glitch reason, I was sure I was posting to
bugzilla. Sorry for that.
Why not configure this group so that it refuses direct posts or
issues warnings?
Re: [Issue 8285] Error passing CTFE-generated string slice to template value parameter
Another test case. The error is different but the root cause must
be the same.
string bar()
{
string s = ab;
return s[0..$];
}
template T1()
{
enum T1 = bar()[0..$]; // error
}
string baz()
{
return T1!();
}
string foo(string s)
{
return s;
}
static assert(foo(baz()) == ab);
void main()
{
}
Error: variable __dollar cannot be read at compile time
Re: [Issue 8285] Error passing CTFE-generated string slice to template value parameter
Reduced test case:
string foo()
{
string s = ab;
return s[0 .. $];
}
template T2(string s)
{
}
template T1()
{
enum s = foo();
alias T2!(s) t2;
}
int bar()
{
alias T1!() t1;
return 0;
}
int baz(int x)
{
return 0;
}
static assert(baz(bar()) == 0);
void main()
{
}
Error: expression ab[0u..2u] is not a valid template value
argument
Re: [Issue 6857] Precondition contract checks should be statically bound.
On Saturday, 5 May 2012 at 05:57:31 UTC, Don wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=6857
--- Comment #46 from Don clugd...@yahoo.com.au 2012-05-04
22:58:38 PDT ---
(In reply to comment #45)
(In reply to comment #44)
But going by comment 26, there is no breakage of correct OOP
behaviour
involved. So how is this relevant?
This has already been covered. We're going in circles.
Walter, you haven't understood this at all. None of us have
claimed that the
program ever gets into a wrong state.
Let me try another way.
Given a module which consists of:
--
struct F {
void foo(int n) in { assert( n 0); } body {}
}
void xyzzy(F f)
{
f.foo(-1);
}
--
A theorem prover, or even a compiler that did basic range
checking for
preconditions, should raise an error at compile time. Not at
run time when it's
actually called with an F, but at compile time. Nothing
controversial there.
Now, change F from a struct to a class. We believe that the
code should still
fail to compile.
Why would one expect the same behavior after changing the struct
to a class? The call to foo in the case of struct is statically
bound. f.foo *cannot* be bound to any other function than the one
declared in F, so it is *always* safe for compiler/theorem prover
to statically check the precondition.
Classes are a different story because of dynamic binding. There
will be cases where compiler/theorem prover will be able to
determine the static type at compile time and detect the error
early. Otherwise, it is obvious that the precondition must be
checked on the dynamic type at run-time.
Re: [Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
On 11/21/2010 08:20 PM, Sean Kelly wrote: d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2834 Max Samukhasamu...@voliacable.com changed: What|Removed |Added CC| |samu...@voliacable.com --- Comment #8 from Max Samukhasamu...@voliacable.com 2010-11-18 03:39:17 PST --- So what is the verdict? Should we simply specify that struct destructors are not automatically called except in RAII and remove the struct-in-class special case? BTW, there are other problems (serious IMO): auto ss = new S[10]; ss.length = 5; delete ss; Destructors are not called on the last 5 elements. auto ss = new S[10]; ss ~= ss; delete ss; We have a nasty problem when destructors are called on the appended elements because postblits was not run for them during append. etc Essentially, operations on arrays of structs with postblits/dtors defined are currently unusable. I think this is unavoidable. Consider: auto a = new T[5]; auto b = a[4..5]; a.length = 4; We can't safely destroy a[4] because it's aliased. Also, since there's no concept of an owner reference vs an alias, modifying the length of b could screw up a as well. For this and other reasons I'm inclined to withdraw this issue, and declare that since structs are value types they won't be automatically destroyed when collected by the GC or when held in arrays. I agree that correct automatic struct destruction is impossible without significant changes to arrays/slices/GC.
Re: Russian and other national languages support
On Tue, 3 Feb 2009 17:13:38 + (UTC), zorran zor...@tut.by wrote:
Russian language not working
in comments and strings by default
with ANSI coding (code page)
Compiler write error - invalid UTF-8 sequence
==
void main()
{
string s = #1063;#1090;#1086;-#1090;#1086; #1087;#1086;
#1088;#1091;#1089;#1089;#1082;#1080;; // some text in russian
printf(hello, world!); //
#1047;#1076;#1088;#1072;#1074;#1089;#1090;#1074;#1091;#1081;,
#1084;#1080;#1088;!
}
==
(D version 1.039)
in Delphi, C#, and many C++ compilers - All OK!
Why?
it can reduce popularity D!
Russian text not needs two-byte code-page! its not Chinese!
D strings are supposed to be UTF-8. Source files can be ASCII or UTF.
To escape a Unicode code point, use \u or \U, where 0 is a
hexadecimal digit. Be aware that dmd/phobos still have some minor
problems with Unicode support. For example, messages produced by
static asserts are not output correctly.
