www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few general thoughts

reply lenochware <lenochware gmail.com> writes:
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 decision have both bad and good sides, which should be
carefully weighted. (I hope that you can understand me, because english is not
my native language)

For me, backward compatibility is important issue. I am sure that this topic
was discussed here many times, but I want just say that I vote for more
careful way to make changes in language. It is even more important for young
language, I believe, because many libraries and tools can stay incompatible
for long time. For example I am not using D2.0, because I have incompatible
libraries in my project and it seems it cannot be fixed easy way.
What about mark features to remove as "deprecated" and write warning by
compiler, if they are used? So feature would be really removed after some time
in next version, and people would be informed this way and have time to
prepare your code or discuss change.

I am not against breaking compatibility entirely, but it should be compensated
with really significant improvement.

Another thing with bad and good sides is "dangerous" feature, as was mentioned
for delete. In my opinion more safety means often more restrictive language
(and now I am speaking in general, not about
"delete"). For example C gives you big freedom, but it is very dangerous.
Modern languages are much more restrictive. But sometimes I prefer dangerous
feature (if it is not "too dangerous"), which give me more freedom. Because
even smartest language designer cannot see all real situations possible and
restriction which cannot be disabled can be very annoying. Example:

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 done with plain ascii. I draw characters in graphic, using OpenGl by
calling glCallLists(somestring.length, somestring.ptr);
It will take somestring as array of indexes of displaylists where each
displaylist will draw one character and his id=ascii code. But because this
restriction it is not possible. And it is error, not
warning and cannot be disabled ANY WAY (as far as I know). You can say: Blah,
utf8 is generally good thing, and this is minor unimportant issue, but I want
just illustrate that restriction can create unexpected problems and that's
because I like if I have choice.
(And again this was not about delete or utf8, but general thougth)

Sorry for long post.
Apr 29 2011
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 29 Apr 2011 12:30:59 +0400, lenochware <lenochware gmail.com>  
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 done with plain ascii. I draw characters in graphic, using OpenGl  
 by
 calling glCallLists(somestring.length, somestring.ptr);
 It will take somestring as array of indexes of displaylists where each
 displaylist will draw one character and his id=ascii code. But because  
 this
 restriction it is not possible. And it is error, not
 warning and cannot be disabled ANY WAY (as far as I know). You can say:  
 Blah,
 utf8 is generally good thing, and this is minor unimportant issue, but I  
 want
 just illustrate that restriction can create unexpected problems and  
 that's
 because I like if I have choice.
 (And again this was not about delete or utf8, but general thougth)

 Sorry for long post.


You can use import("file.txt"); to import files (text or binary) at  
compile time.

You source code however *SHOULD* remain in UTF-8 (with ASCII being a  
subset of it).
Apr 29 2011
next sibling parent Alexander <aldem+dmars nk7.net> writes:
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
Apr 29 2011
prev sibling parent reply lenochware <lenochware gmail.com> writes:
== Quote from Denis Koroskin (2korden 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...
Apr 29 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Apr 29, 11 17:53, lenochware wrote:

 == Quote from Denis Koroskin (2korden 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...


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 = [0xf1, 0xf2, 0xf3, 0xf4];
     auto t = cast(const(ubyte)[]) x"f1f2f3f4";

)
Apr 29 2011
parent reply lenochware <lenochware gmail.com> writes:
== Quote from KennyTM~ (kennytm 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 = [0xf1, 0xf2, 0xf3, 0xf4];
      auto t = cast(const(ubyte)[]) x"f1f2f3f4";
 )


It would be very unclean write strings this way, but it is not so important. The
point is that I don't like features which cannot be disabled. For example
variables in D are initialized, which is good, but you can write int i = void;
and
disable it. The final decision is on the programmer. You are not forced to do it
only one "good" way.
This is philosophy which I like.
Of course, I understand that it is not possible make everything optional, it has
negatives, like everything has, but if there are serious doubts about some
feature
and it is not big deal to make it optional, it SHOULD be optional. At least I
think so.
May 01 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On May 1, 11 21:23, lenochware wrote:

 == Quote from KennyTM~ (kennytm 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 = [0xf1, 0xf2, 0xf3, 0xf4];
       auto t = cast(const(ubyte)[]) x"f1f2f3f4";
 )


 It would be very unclean write strings this way, but it is not so important.


It's very *unportable* to write a string in your way. Not every 
editor/OS default to ISO-8859-1 when an encoding is not found (say 
Notepad.exe), and your source file is likely destroyed because when I 
"Save As..." it all those 'åéüîø' becomes '?????', or the file is 
re-encoded into UTF-8, and the program will think you've actually 
written 'åéüîø'.

(Of course that also happens to UTF-8. Therefore it's best to restrict 
to ASCII only.)


 The point is that I don't like features which cannot be disabled. For 


example

 variables in D are initialized, which is good, but you can write int i = void;
and
 disable it. The final decision is on the programmer. You are not forced to do
it
 only one "good" way.


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.

That's different from '= void' or 'cast' is those are *explicit*.


 This is philosophy which I like.
 Of course, I understand that it is not possible make everything optional, it
has
 negatives, like everything has, but if there are serious doubts about some
feature
 and it is not big deal to make it optional, it SHOULD be optional. At least I
 think so.


Yes it's possible that DMD add a -wno-utf-warning switch. But you'd have 
better chance convincing Walter to split the different -w options :).
May 01 2011
parent lenochware <lenochware gmail.com> writes:
== Quote from KennyTM~ (kennytm 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 generate just warning, not error...
May 03 2011
prev sibling next sibling parent reply Francisco Almeida <francisco.m.almeida gmail.com> writes:
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) compatibility?


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 recompile. As an unfortunate side effect, a few other 
problems might occur, especially for shared objects. But refactoring to 
a simpler system, in which the garbage collector is trusted to manage 
the heap, should be easy.

Keep in mind though, most manual memory management done in D was done 
using D1, which will *not* have its delete operator removed. Only D2 
will see the change.


 In my opinion every decision have both bad and good sides, which should be
 carefully weighted. (I hope that you can understand me, because english is not
 my native language)


I too had a lot of concern (and was pretty vocal about it), but there 
are few misconceptions people often have:

- The removal of delete does *not* prevent one from doing manual memory 
management. malloc/free are available, as well as the emplace() function 
that allows to declare class objects on the C heap.

- The removal of delete does *not* remove RAII from the language. There 
is now an important semantical separation between struct and class: 
structs are declared on the stack by default, are scoped, and can use 
the traditional scheme of being initialized in the constructor and 
terminated in the destructor. Classes are garbage collected by default.


 For me, backward compatibility is important issue. I am sure that this topic
 was discussed here many times, but I want just say that I vote for more
 careful way to make changes in language. It is even more important for young
 language, I believe, because many libraries and tools can stay incompatible
 for long time. For example I am not using D2.0, because I have incompatible
 libraries in my project and it seems it cannot be fixed easy way.
 What about mark features to remove as "deprecated" and write warning by
 compiler, if they are used? So feature would be really removed after some time
 in next version, and people would be informed this way and have time to
 prepare your code or discuss change.


If you are still using D1, do not worry. D1 code should unaffected by 
the change.


 I am not against breaking compatibility entirely, but it should be compensated
 with really significant improvement.


There are enough improvements in my opinion. :)


 Another thing with bad and good sides is "dangerous" feature, as was mentioned
 for delete. In my opinion more safety means often more restrictive language
 (and now I am speaking in general, not about
 "delete"). For example C gives you big freedom, but it is very dangerous.
 Modern languages are much more restrictive. But sometimes I prefer dangerous
 feature (if it is not "too dangerous"), which give me more freedom. Because
 even smartest language designer cannot see all real situations possible and
 restriction which cannot be disabled can be very annoying.


This is a discussion I can still go into ocasionally. The philosophy of 
"making what is best easier and what is wrong harder" can lead to 
undesired consequences. Who is to decide what approach is "right" or 
"wrong" for each problem?

With delete, I have reached the conclusion that this is not the case 
however. 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.
Apr 29 2011
next sibling parent Alexander <aldem+dmars nk7.net> writes:
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.

/Alexander
Apr 29 2011
prev sibling parent reply lenochware <lenochware gmail.com> writes:
 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 recompile. As an unfortunate side effect, a few other
 problems might occur, especially for shared objects. But refactoring to
 a simpler system, in which the garbage collector is trusted to manage
 the heap, should be easy.


Yes, I was speaking generally here about "breaking compatibility" philosophy.
I agree that delete probably will not be such problem - but I would prefer mark
features deprecated
before it will be really removed and write only warning when compiled - in case
it
is possible. (For example some datatype was removed in d2 (bit? - I am not sure)
which is one of error messages which I get when I try compile my project with
incompatible library) People don't have to know what is planned for removing.
Moreover there is not complete list of changes in d2. Or is?
Apr 29 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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 easy: just
 remove them, and recompile. As an unfortunate side effect, a few other
 problems might occur, especially for shared objects. But refactoring to
 a simpler system, in which the garbage collector is trusted to manage
 the heap, should be easy.


 Yes, I was speaking generally here about "breaking compatibility" philosophy.
 I agree that delete probably will not be such problem - but I would prefer mark
 features deprecated
 before it will be really removed and write only warning when compiled - in
case it
 is possible. (For example some datatype was removed in d2 (bit? - I am not
sure)
 which is one of error messages which I get when I try compile my project with
 incompatible library) People don't have to know what is planned for removing.
 Moreover there is not complete list of changes in d2. Or is?


Who said that delete will not be marked deprecated before it's removed?
Apr 29 2011
next sibling parent Don <nospam nospam.com> writes:
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 which the fix is quite easy: just
 remove them, and recompile. As an unfortunate side effect, a few other
 problems might occur, especially for shared objects. But refactoring to
 a simpler system, in which the garbage collector is trusted to manage
 the heap, should be easy.


 Yes, I was speaking generally here about "breaking compatibility" 
 philosophy.
 I agree that delete probably will not be such problem - but I would 
 prefer mark
 features deprecated
 before it will be really removed and write only warning when compiled 
 - in case it
 is possible. (For example some datatype was removed in d2 (bit? - I am 
 not sure)
 which is one of error messages which I get when I try compile my 
 project with
 incompatible library) People don't have to know what is planned for 
 removing.
 Moreover there is not complete list of changes in d2. Or is?


 
 Who said that delete will not be marked deprecated before it's removed?


Take a lesson from history:
-----------
What's New for D 0.116
Mar 7, 2005
New/Changed Features

$ can now be used instead of length inside an array's []. It represents 
the length of the array. This is a trial feature, if it works out then 
these will happen in sequential releases:

1. length will become deprecated inside [].
2. length will be removed as the implicitly declared length, and it will 
be just another identifier.
-----------
Exactly five years later, step 1 was implemented, but only for D2:
-----------
Version D 2.041 Mar 7, 2010
New/Changed Features

Use of length inside of [ ] is now deprecated, use $ instead
-----------
We're still waiting for step 2.
Apr 29 2011
prev sibling parent reply Francisco Almeida <francisco.m.almeida gmail.com> writes:
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 delete statements, for which the fix is quite easy: just
 remove them, and recompile. As an unfortunate side effect, a few other
 problems might occur, especially for shared objects. But refactoring to
 a simpler system, in which the garbage collector is trusted to manage
 the heap, should be easy.


 Yes, I was speaking generally here about "breaking compatibility"
 philosophy.
 I agree that delete probably will not be such problem - but I would
 prefer mark
 features deprecated
 before it will be really removed and write only warning when compiled
 - in case it
 is possible. (For example some datatype was removed in d2 (bit? - I am
 not sure)
 which is one of error messages which I get when I try compile my
 project with
 incompatible library) People don't have to know what is planned for
 removing.
 Moreover there is not complete list of changes in d2. Or is?


 Who said that delete will not be marked deprecated before it's removed?


I apologize, I meant "warning" instead of "error". Deprecation warnings, 
obviously.
Apr 29 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
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 compiler will probably issue error messages once it
 encounters delete statements, for which the fix is quite easy: just
 remove them, and recompile. As an unfortunate side effect, a few other
 problems might occur, especially for shared objects. But refactoring to
 a simpler system, in which the garbage collector is trusted to manage
 the heap, should be easy.


 Yes, I was speaking generally here about "breaking compatibility"
 philosophy.
 I agree that delete probably will not be such problem - but I would
 prefer mark
 features deprecated
 before it will be really removed and write only warning when compiled
 - in case it
 is possible. (For example some datatype was removed in d2 (bit? - I am
 not sure)
 which is one of error messages which I get when I try compile my
 project with
 incompatible library) People don't have to know what is planned for
 removing.
 Moreover there is not complete list of changes in d2. Or is?


 Who said that delete will not be marked deprecated before it's removed?


 
 I apologize, I meant "warning" instead of "error". Deprecation warnings,
 obviously.


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
Apr 29 2011
next sibling parent lenochware <lenochware gmail.com> writes:
== Quote from Daniel Gibson (metalcaedes 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 didn't know that it is already working this way.
Apr 29 2011
prev sibling parent Alexander <aldem+dmars nk7.net> writes:
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, some not...

  All-or-nothing is right, but not always good.

/Alexander
Apr 29 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
 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 decision have both bad and good sides, which should be
 carefully weighted. (I hope that you can understand me, because english is
 not my native language)
 
 For me, backward compatibility is important issue. I am sure that this
 topic was discussed here many times, but I want just say that I vote for
 more careful way to make changes in language. It is even more important
 for young language, I believe, because many libraries and tools can stay
 incompatible for long time. For example I am not using D2.0, because I
 have incompatible libraries in my project and it seems it cannot be fixed
 easy way.
 What about mark features to remove as "deprecated" and write warning by
 compiler, if they are used? So feature would be really removed after some
 time in next version, and people would be informed this way and have time
 to prepare your code or discuss change.
 
 I am not against breaking compatibility entirely, but it should be
 compensated with really significant improvement.


The decision on removing delete was made some time ago. It just hasn't been 
done yet. The same goes for a few other features such as scoped classes. 
However, aside from already planned changes, there shouldn't be many breaking 
changes to the language in the near future. D2 is supposed to be finalized 
enough with the release of TDPL, that breaking changes should be fairly rare. 
There are still things that need to be sorted out and some breaking changes 
may be necessary, but it shouldn't be all that common.

The general philosophy on breaking changes at this point though is to do it in 
stages. First, the compiler will complain at you. Following that, the item 
will be deprecated, and you'll have to compile with the -d flag or your code 
won't compile. Finally, the item will be removed completely, and any code 
which still uses it will break. I'm not sure that _all_ breaking changes will 
be able to have that smooth a transition, but that's the goal.

- Jonathan M Davis
Apr 29 2011