Hacker News Reader

Comment by cogman10 | Hacker News Reader

Counter point, my day to day programming is in GC languages. In those, how long something lives is basically anyone's guess, could be the entire length of the program, could be 2 seconds from now.

This isn't something that really causes headaches, it's desirable. So long as when you come in conflict with the borrow checker there's an ability to unwind it, I don't see the harm.

My assumption is the lifetime explanation while incorrect will also still work (I couldn't imagine it wouldn't as that'd break too much). So assuming you do run into these compiler problems, you can still revert to the old simpler mental model and move forward.

View on HN

Only if we are talking about GC languages without value types support.

Examples of languages with some form of automatic memory management and RAII.

Swift, D, Nim, C#, Active Oberon, Modula-3, Delphi.

Every language I'm aware of has value types (but not user defined value types). Typically numerics or "primitives" are value types in GCed languages.

Those types don't have any sort of explicit lifetime that are different from a regular object type. If you put a `int` on a `Foo` object that `int` lives as long as the `Foo` object does, for example.

Being a value type simply means that the memory representation of the value is used instead of a pointer/object reference.

That means that even when you do have user defined value types the same rules apply. How long these things "live" depends entirely on the context of what they are associated with. If you have a `Bar` value type on a `Foo` object then `Bar` will live as long as `Foo` does, which means till the next garbage collection.

The ones I listed have classical C and C++ like value types available to them, with stack allocation or global memory segments, and mechanisms to do deterministic resource management.

Instead you decided to point out the philosophical meaning of value types.

I think he's pointing out that value types and "does this language require/support explicit lifetime management" are actually unrelated. Fortran has value types but it doesn't have built-in memory management features. Perhaps you could substitute "has heap allocation" for "has value type"?

Fortran has had allocatables for 34 years.

What do you mean by

> The ones I listed have classical C and C++ like value types available to them

I don't really know what that means or how it's related to the discussion of lifetimes.

Deterministic resource management.

As I said and covered, value types are not deterministic resource management. Those are orthogonal concepts.

And in fact, confusing the two can lead to problems. C#, for example, does not necessarily store value types on the stack. [1] Those can be allocated on the heap. C# doesn't even give a guarantee of how long a value type will live. It's only guarantee is the one I outlined earlier, that this thing is represented as a block of memory rather than a pointer and that when you pass this around it's done as a copy.

If your assumption is that "this thing is freed up immediately when it's unused" that's a faulty assumption. Being a value type imparts no guarantee on how long something will live.

This is more than just a philosophical definition.

If you want deterministic resource management in C#, you use the `using` statement. If you are in java, it's `try-with-resources`. If you are in C++, you rely on RAII. If you are in C... good luck. None of those things have anything to do with value types. Because lifetime and type aren't related in those languages

> Once you abandon entirely the crazy idea that the type of a value has anything whatsoever to do with the storage, it becomes much easier to reason about it.

[1] https://ericlippert.com/2010/09/30/the-truth-about-value-typ...

This is an ancient article. Pretty much only Rust has .drop() with such strong steroids. Either way struct in C# means something very specific and it is the same as struct in C. You can cast a malloced pointer in C to a struct and use it as such, you can do the same in C# (not that you should, but you can).

In terms for article contents - structs absolutely do go on the stack when you declare them as locals except select scenarios: async and iterator methods, both of which can capture variables that live across yields or awaits into a state machine struct or class (debug/release difference, and also ValueTask which does not alloc when it completes synchronously).

If you care about memory lifetimes, the compiler will helpfully error out when you are returning a 'ref' to a local scope, violating the lifetime (because it has rudimentary lifetime analysis underneath hence scoped and unscoped semantics).

> This is an ancient article.

It was posted yesterday, 4 March 2024.

I meant the Eric Lippert one :)

It talks about that spec does not say where structs go. And yet, all existing implementations today have more or less identical behavior (and by all I mean .NET (CoreCLR), Mono (the dotnet/runtime flavour), Mono (the Unity flavour) and .NET Framework.

With that said, only respect to the article's content and, of course, Eric Lippert. For the context of the discussion, however, it may be misleading. C# has gained quite a few low level primitives since it has been written too.

Ah! My bad for misunderstanding.

> C#, for example, does not necessarily store value types on the stack

It does if you use the right set of keywords, learn them.

... And memory/resource leakage is not an uncommon problem in those languages

Reply on news.ycombinator.com