This post is in fact mainly about removing delete, but I didn't wont make
everyone angry just with title.:) I am sure not expert to language design, so
I should probably be quiet, but I have question.
My question is: Didn't break it (i.e. removing delete) compatibility?
In my opinion every decisio
On Fri, 29 Apr 2011 12:30:59 +0400, lenochware
wrote:
I was not happy with error message "invalid utf8 character". I am using
international character in my strings and compiler gives me this
message. Of
course, I can switch my source codes into utf8, but here are few tricks
which
can be d
On 29-04-2011 10:30, lenochware wrote:
This post is in fact mainly about removing delete, but I didn't wont make
everyone angry just with title.:) I am sure not expert to language design, so
I should probably be quiet, but I have question.
My question is: Didn't break it (i.e. removing delete) co
On 29.04.2011 10:54, Francisco Almeida wrote:
> The options for memory management are still kept open, and the best we can do
> is hope that the GC is improved in the near future.
I'd say that *before* this happens actually (very effective GC), it is a bit
too early to deprecate delete.
/Ale
On 29.04.2011 10:42, Denis Koroskin wrote:
> You source code however *SHOULD* remain in UTF-8 (with ASCII being a subset
> of it).
If it "should", not "must" - then there should be switch to disable this
restriction, IMHO ;)
/Alexander
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
> You can use import("file.txt"); to import files (text or binary) at
> compile time.
Interesting - I didn't know this. It's true that most of strings will be
probably
loaded from some file in final application...
> This has been acknowledged. Yes, removing delete in D2 will break
> compatibility with existing code. However, I'm sure that at an early
> stage, the compiler will probably issue error messages once it
> encounters delete statements, for which the fix is quite easy: just
> remove them, and recomp
Am 29.04.2011 12:11, schrieb lenochware:
This has been acknowledged. Yes, removing delete in D2 will break
compatibility with existing code. However, I'm sure that at an early
stage, the compiler will probably issue error messages once it
encounters delete statements, for which the fix is quite e
Daniel Gibson wrote:
Am 29.04.2011 12:11, schrieb lenochware:
This has been acknowledged. Yes, removing delete in D2 will break
compatibility with existing code. However, I'm sure that at an early
stage, the compiler will probably issue error messages once it
encounters delete statements, for wh
On 29-04-2011 12:37, Daniel Gibson wrote:
Am 29.04.2011 12:11, schrieb lenochware:
This has been acknowledged. Yes, removing delete in D2 will break
compatibility with existing code. However, I'm sure that at an early
stage, the compiler will probably issue error messages once it
encounters dele
Am 29.04.2011 13:11, schrieb Francisco Almeida:
> On 29-04-2011 12:37, Daniel Gibson wrote:
>> Am 29.04.2011 12:11, schrieb lenochware:
This has been acknowledged. Yes, removing delete in D2 will break
compatibility with existing code. However, I'm sure that at an early
stage, the co
== Quote from Daniel Gibson (metalcae...@gmail.com)'s article
> Once a feature is deprecated, the compiler will treat using it as an
> error - *if* you don't use the "-d" switch ("Allow deprecated features").
> I think this should be acceptable for you?
> Cheers,
> - Daniel
Seems good. Sorry, I di
On 29.04.2011 14:03, Daniel Gibson wrote:
> Once a feature is deprecated, the compiler will treat using it as an
> error - *if* you don't use the "-d" switch ("Allow deprecated features").
Probably it would be a better choice to selectively disable deprecated
features - some may be fixed quick
On Apr 29, 11 17:53, lenochware wrote:
== Quote from Denis Koroskin (2kor...@gmail.com)'s article
You can use import("file.txt"); to import files (text or binary) at
compile time.
Interesting - I didn't know this. It's true that most of strings will be
probably
loaded from some file in final
> This post is in fact mainly about removing delete, but I didn't wont make
> everyone angry just with title.:) I am sure not expert to language design,
> so I should probably be quiet, but I have question.
> My question is: Didn't break it (i.e. removing delete) compatibility?
>
> In my opinion e
== Quote from KennyTM~ (kenn...@gmail.com)'s article
> You could use x"" string, or just escape those characters
> auto x = x"f1f2f3 f4";
> auto y = "\xf1\xf2\xf3\xf4";
> (And if your "string" is not a UTF-8 string at all, you should use a
> ubyte[], not char[].
> const(ubyte)[] z =
On May 1, 11 21:23, lenochware wrote:
== Quote from KennyTM~ (kenn...@gmail.com)'s article
You could use x"" string, or just escape those characters
auto x = x"f1f2f3 f4";
auto y = "\xf1\xf2\xf3\xf4";
(And if your "string" is not a UTF-8 string at all, you should use a
ubyte[], not
== Quote from KennyTM~ (kenn...@gmail.com)'s article
> It's very *unportable* to write a string in your way.
Yes, that's probably true.
> If D allowed non-UTF encoding without error, it's possible that a string
> in those settings got misinterpreted, but it's not easy to determine when.
Could be
18 matches
Mail list logo
