Add prescription property or func/closure to "CustomStringConvertible"

In the world of linguistics, we have a duality of "prescriptivism" and "descriptivism". In the foolish war between people of both sides, truth is , "prescription" and "description" are coupled with each other in all world languages, perhaps with 1 of the 2 being more dominating in its influence on the whole language that we are examining.

As follows from language, it should be implemented in Programming languages. What I propose, is pretty much adding a "prescription" String property to "CustomStringConvertible" OR have it as a func that computes hashes.

I do this for enums but haven't fully been able to tap into the real power of "prescription" values in my enums because I feel I may need to learn how to create hashing systems as well as know how to use key paths. But also, I wonder if "prescriptions" are more appropriate as a function rather than a property since we as humans function on the prescriptions we assign to objects.

My personal use of "description" is more for values context needed for showing the user.
My personal use of "prescription" is more for referencing contexts I need as a developer.

I am interested in what you have to say about this.

To start, perhaps you could give an example?

protocol CustomStringConvertibleWithPrescription : CustomStringConvertible {
     func prescribe() -> String
     // alternatively you can have a var instead
     // var prescription : String
enum Hobby : CustomStringConvertibleWithPrescription {
    case meditate
    case program
    case philosophy

    var description: String {
       switch self {
       case .meditate:
           return "Meditate"
       case .program:
           return "Program"
       case . philosophy:
           return "Philosophy"

    func prescribe() -> String {
     // would likely need a "nonce" int value so each time an instance of Hobby is initialized,
    // it can generate a different hash that can still be linearized to the all hashes of a specific "case" of a hobby instance. 
       switch self {
          case .meditate:
              return "\("\("Meditate".hashValue)")"
       case .program:
          return "\("\("Program".hashValue)")"
       case . philosophy:
          return "\("\("Philosophy".hashValue)")"


I still don’t understand. How would you use the prescribe method or variable?

Thats what we are trying to philosophize on. You must first understand the concept of "prescriptivism" and "descriptivism" first. Its because of linguistics that the field of computer science was born. My point is that we must have both elements in programming. What It means to "describe" is already given to us in Swift which is consistent with the definition of "description". But we don't have such a thing for "prescribe" because we haven't been able to translate what it means to "prescribe" into how we code programs.

I think you are either trolling us (in that case please stop), or are seriously overthinking things (in which case I would also suggest to stop).

I admit I don't understand what you mean exactly by these words, especially in the context of a computer language. So please humour me and explain. Thank you.

Language is the dawn of our perception and we have used our evolved language to defined a subset language for our computers to have a perception (thats obviously lower than us).

We use language to describe the world but also prescribe the rules that generate our world.

Same should apply to computers.

I've made things very simple.

Ive nothing more to say because the basics you dont understand.

I encourage you to "humour" yourself with language.

I hope you are not a practitioner in AI because saying that is quite embarrassing.

Please refrain from speaking down to members of the community. It makes it less inviting to newcomers and harms your argument.


So if I understand the entire point of this thread. It is that you want every instance of all types (struct and enum) to all have unique reference id’s. Similar to what classes have now?

I think this sort of pseudophilosophical discussion of values is quite a few shades too abstract to lead to useful design results, and I agree with Erik that the condescension is totally inappropriate. I'm going to close this thread. MTV, if you'd like to study the community better and start over with a more concrete expression of your idea, you are welcome to if you can refrain from insulting people the next time.