Well, it's clearly not helping them, is it?  Most programmers may or may not know what in the world they're doing, but most of the programmers I want to hire or have work with me will.

All of the features you listed are there to help people who are sensible detect errors.  Lovely things they are, too.  But they don't just get used, you have to use them.  If you don't, you're no better off than if you didn't.

Mistakes happen, but gross mistakes shouldn't.  If they do, the person needs to go back and bake in training/school/less important projects for a while.  No language can change this, however many keywords or flags it adds.

-[Unknown]


> Most programmers are amateurs; you're not going to change that.

Matthew wrote:
>>I am in no way trying to attack you. I am just pointing out that C and
>>C++ breeds bad programming practice, and we need protection from them.
>  [snip]
> Bottom line: if you're a good engineer, you're a good engineer. If you're not, you're not. The language used won't affect this truth. And avoiding peaking inside abstractions won't help you become one.

I think you didn't get his point: he's not worried that /he/ will misuse pointers, he's worried that _his colleagues_ will.

> I will skip the "pointers are unsafe" rigmarole.
>
> Should D provide something analogous to the C# unsafe keyword?


If "safe" means "managed" and
 "unsafe" means "unmanaged" then answer is no.
By definition as  D code is "unmanaged".

To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you.

Andrew.

By implementation detail, are you speaking to it nulling the pointer?  I was pretty sure that was in the spec, and not in the implementation.

Delete is needed if you ever want to immediately call a destructor.  If used wisely, it can also decrease the memory usage of your software, and reduce garbage collection runs (if the GC won't run unless there's more than X to collect.)

Overriding new and delete would definitely fit into the same class as pointers, recursion, casting, != in fors, and delete.  They're all scary.

-[Unknown]


> Chris Miller wrote:
>> On Mon, 13 Feb 2006 00:26:48 -0500, nick <nick.atamas@gmail.com> wrote:
>>
>>> Now you're talking crazy talk. Throws declarations may be a bad idea - I
>>> agreed after having read up on it. I have yet to hear a good reason why
>>> the unsafe keyword or some other safeguard against dangerous pointer
>>> code is a bad idea.
>>>
>> Then would 'delete' be 'unsafe'? Even though it nulls the reference,
>> other places may still be referencing it, hence making it unsafe.
> 
> That seems to be an implementation detail. However, my immediate
> reaction is that delete probably should be unsafe; however, I am not
> sure. It all depends on how much it is needed for mainstream software
> development and how much damage it tends to cause.
> 
> Of course, if you are talking about overriding new and then calling
> delete, that's a different story. By allocating memory manually you are
> preventing a good garbage collector from optimizing your heap, so you
> should be avoiding that in most cases.
> 
> The upshot of using "unsafe" is that all code that messes with the
> memory manually would get marked unsafe. So, someone working on OS
> features may end up having to put an "unsafe:" at the top of every file
> and compiling with the --unsafe flag (or something to that effect). It
> seems like a small price to pay for preventing amateurs from screwing up
> your code.
> 
> It seems to me that most people who write code don't need pointers. Both
> D and C++ are languages that provide high-level and low-level access.
> You are going to get both experts who need the pointers and amateurs who
> don't need them.
> 
> Both Bjarne and Matthew seem to think that people should just "learn to
> code well". Despite admitting that most coders are not experts, Bjarne says:
> 
> "The most direct way of addressing the problems caused by lack of type
> safety is to provide a range-checked Standard Library based on
> statically typed containers and base the teaching of C++ on that".
> <http://public.research.att.com/~bs/rules.pdf>
> 
> I must disagree. There are too many people to teach. In some cases it is
> a lot easier to modify a language than to teach everyone not to use a
> feature. This may be one of those cases. I think experts tend to forget
> that a language is there to help programmers develop software and to
> reduce chances of human error.

Why don't you give them access to a scripting language?  Perhaps something like Python/Ruby or even DMDScript?

If performance is an issue, just make sure the scripting language doesn't allow eval (which is so much more evil than pointers, by the way) and you should be able to convert easily.

-[Unknown]


> Note: I did a search for this and didn't come up with any threads. If it
> has been discussed before... my apologies.
> 
> 
> Recently I introduced D to a friend of mine (a C.S. grad student at
> Purdue). His reaction was the usual "wow, awesome". Then he became
> concerned about pointer safety. D allows unrestricted access to pointers.
> 
> I will skip the "pointers are unsafe" rigmarole.
> 
> Should D provide something analogous to the C# unsafe keyword?

On Sun, 12 Feb 2006 22:33:25 -0800, Unknown W. Brackets wrote:

>> Most programmers are amateurs; you're not going to change that.

More indication that we could really do with a 'lint' program for D. It could warn about pointer usage too.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
13/02/2006 5:44:24 PM

Pointer problems are notoriously difficult to track. Pointers are a feature that is not necessary in 90% of production code. Hey, Joel called them DANGEROUS. (I'm going to use that one a lot now.)

My example demonstrates a potential error that, if occurs in a library that you don't have source for, will cause you hours of grief. My example was carefully constructed. In it an object was passed in using the /in/ keyword. That should guarantee that my copy of the object doesn't change. If you are saying it is OK for it to change, then you are basically saying that the /in/ keyword is useless (well, not really useless but almost). I don't think that's cool.

Unknown W. Brackets wrote:
> What's going to stop them from making other mistakes, unrelated to pointers?  For example, the following:
> 
> void surprise(in char[] array)
> {
>     ubyte[100] x = cast(ubyte[100]) array;
>     array[99] = 1;
> }
> 
> This will compile fine, and uses zero pointers.  It's exactly the same concept, too.
No, it won't compile. Maybe I have a different version of dmd, but I get
this:
main.d(3): e2ir: cannot cast from char[] to ubyte[100]

Try it yourself.

The rest of these aren't really pointer bugs. So, if you want to try a slippery slope and argue that all of programming is unsafe, be my guest. It isn't particularly productive though. (Sorry, I am getting cranky; it's late.)

Here's another one:
> 
> void surprise(in int i)
> {
>     if (i == 0 || i > 30)
>         return i;
>     else
>         return surprise(--i);
> }
> 
> Oops, what happens if i is below 0?  Oh, wait, here's another common mistake I see:
> 
> for (int i = 0; i != len; i++)
> {
>     ...
> }
> 
> What happens if len is negative?  I've seen this happen, a lot, in more than a few different people's code.  They weren't stupid, you're right, but it did happen.
> 
> So do we mark != in fors as "unsafe"?  Recursion too?  And forget casting, any casting is unsafe now as well?
> 
> Seems to me like you're going to end up spending longer dealing with their problems, if they think they can use pointers but really can't, than you would just reviewing their darn code.
> 
> Oh wait, it's only open source where you do that "code review" thing.
> Otherwise it's considered a waste of time, except in huge corporations.
>  Why bother when "unsafe" can just fix everything for you like magic?
> 
> Valentine's day is coming up... good thing there are flowers, they just
> fix everything too.  I can be a jerk and all I need are flowers, right?
>  Magic.
> 
> -[Unknown]

Unknown W. Brackets wrote:
> Well, it's clearly not helping them, is it?  Most programmers may or may not know what in the world they're doing, but most of the programmers I want to hire or have work with me will.
> 
> All of the features you listed are there to help people who are sensible detect errors.  Lovely things they are, too.  But they don't just get used, you have to use them.  If you don't, you're no better off than if you didn't.
> 
> Mistakes happen, but gross mistakes shouldn't.  If they do, the person needs to go back and bake in training/school/less important projects for a while.  No language can change this, however many keywords or flags it adds.
> 
> -[Unknown]
> 
> 
>> Most programmers are amateurs; you're not going to change that.

That's an easy one. You can't do unsafe things without wrapping your code in the unsafe keyword. That's fairly easy to add, if you ask me. However, when that amateur gets the compiler error, he/she will look it up. Once they do, there will be a big notice "DANGER, USE THIS INSTEAD".

I work with a lot of EEs who only had one or two programming courses. They get a job mainly based on their hardware architecture knowledge. Now they have I have to work with them and write a hardware simulator.

Oh, I don't know if you realize this, but essentially removed /in/out/inout from the D spec with my example; please go read it.

If you think that people are going to use the language the RIGHT way when there is such a tempting wrong way, I suggest you look at C++ and its operator overloading.

Andrew Fedoniouk wrote:
>> I will skip the "pointers are unsafe" rigmarole.
>>
>> Should D provide something analogous to the C# unsafe keyword?
> 
> 
> If "safe" means "managed" and
>  "unsafe" means "unmanaged" then answer is no.
> By definition as  D code is "unmanaged".
> 
> To implement realy "safe" mode (whatever it means) you need at least VM creating safe sandbox for you.
> 
> Andrew.

I didn't say I had a solution, I just said I have a problem. The "unsafe" thing is just some syntax that looked pretty cool in C#.

If c-style pointers are left the way they are now, you might as well not have in/out/inout parameters. To save you from reading the rest of the thread, here is an example:

CODE:
-----

import std.stdio;

class A
{
	private int data[];

	public this()
	{
		data.length = 10;
	}

	public void printSelf()
	{
		writefln("Data: ", this.data);
	}
}

void surprise(in A a)
{
	byte *ap = cast(byte *)(a);
	ap[9] = 5;
}

int main()
{
	A a = new A();
	a.printSelf();
	surprise(a);
	a.printSelf();
	return 0;
}


OUTPUT:
-------

Data before surprise: [0,0,0,0,0,0,0,0,0,0]
Data after surprise:
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4287008,0,2004,216,1245184,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855552,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,8855680,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8855808,
<..SNIP..>
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]

Derek Parnell wrote:
> On Sun, 12 Feb 2006 22:33:25 -0800, Unknown W. Brackets wrote:
> 
>>> Most programmers are amateurs; you're not going to change that.
> 
> More indication that we could really do with a 'lint' program for D. It could warn about pointer usage too.
> 
> 
A lint-like tool may be the way to go. However, there definitely need to be an in-language solution to the /in/ parameter problem. That seems to be unacceptable (see my previous posts for the details).

There is a lint-like project for Java called Find Bugs. Bill Pugh at UMCP is leading it. I happen to know Dr. Pugh; he taught one of my courses and sponsored my senior C.S. project. If someone decides to work on a lint-like tool, I will be happy to introduce them to Dr. Pugh.