ianhedoesit

Isn't this still a useful feature? You still at least have a better idea of where to look compared to C. With the feature of `unsafe` blocks in Rust you have points of entry to look at, and can be relatively sure that you only need to follow the several methods that are used in the `unsafe` block at most. In C you can happily have `some_function_1()` which causes the error you're trying to debug happen but is never called anywhere near where the error gets thrown.

Tracking a semantic error in a call that's three calls away from where your unsafe block lives is much easier and structured than going through everything everywhere for any error from anything.

(I haven't done much work at all in Rust and avoid `unsafe` - and `mut` and `.unwrap`, for that matter - like the plague when I do use it, so I'm very open to being wrong in my interpretation.)

EDIT: I also think a reasonable comparison would be Haskell's `do` blocks. It's guaranteed that anything with side effects will live in a `do` block, but of course you can still have semantic errors. Again, you know exactly the "functions of interest" to look at if this is the case - there's no chance of `someFunc1` to be doing anything funny if it's never called by anything in the `do` block.

I think this StackExchange question is pretty useful. http://programmers.stackexchange.com/questions/107687/what-i...

I think what yason was trying to say is that how it currently works isn't the best option, but neither are obvious alternatives, such as making it a financial investment to send takedown notices.

Ah, great. Thank you. I still find it a bit odd how they have made the connection, especially with a language that doesn't have that much adoption. But maybe that's why I don't work for Microsoft.

I can't find an accompanying article or anything for this. I'm curious as to why Microsoft would put something like this out? Why make the comparison in the first place? Why compare it to Swift?

Also, the code at http://aka.ms/scspostercode is nice.

I would imagine it was more of the opposite scenario. Rather than calling your girlfriend when you forget to lock your house, you might want to just lock it remotely.

I have never seen anywhere require "Address Line 2." It's only used as a specifier to the address when there are multiple units at the address (office buildings, apartments, and the like).

The major difference I've found is that /d is more akin to *nix symlinks with few exceptions, and /j is an NTFS-specific, local-only, directory link. Links made with the /d option can be files or directories to local or remote file system.[1] Junction points can only point to local directories, and have a few other limitations in regards to the Windows startup process.[2] As far as I can tell, symbolic links created with mklink /d are just improved versions of NTFS junction points.

[1] http://en.wikipedia.org/wiki/Symbolic_link#Microsoft_Windows

[2] http://en.wikipedia.org/wiki/NTFS_junction_point