Its saying make sure the implementation of description matches the directions hint: string interpolation

First off, I'm assuming that not all tasks are verified by the backend just checking one line of STDOUT, one function's return data, or one var/const equality check. I think it is quite a worthy tradeoff for many autograders ala years 1 and 2 of University CS. I have seen in OS code and imagine functions in the task/quiz subtree here that are hortcuts/hacks/ingenuity that the TT's compiler pre/post compile hookss may use to check correctness (under the scope of the task's expectation, not like Hoare triples) by using much simpler and muuuuuuuuch quicker and easier to understand checks that may cut a few corners. (That's okay - the alternative is find a perfect and v. expensive enterprise grade code autograder with enough flexibility for your needs, which isn't realistic to most people - we just wanna stop the students, be they my pupils as a TA or Treehouse's voluntary students, from entirely trivializing the assignment, which tends to have no randomized constant to change the specific value of the end result or very simple ones. It's clear that just having a function return the trivial, already easily known final answer in whatever format, or similarly prints it or whatever the case may be. If it's a random constant that you don't know, then you 99% of the time you can't do this most powerful and most easily mitigated "attack" even when you're given the answer directly by the first run of the autograder. Other mitigations could be.... a whole lot of regex's. Very easy to write a regex and match it on your return data to see if it has the syntax formulations we want. Harder but doable to make it better and fuzzier. And, this is essentially what you did. You treat Tag, a struct, just as if it were another Swift fundamental type with type literals... which are usually what you use in interpolation. It's sheer luck that your struct being interpolated. it's not, it's a struct for semantic reasons and to instill good design patterns and code smell avoidance into students techniques, It's a a .particular, uniquely classified data structure with its own meaning. In fact, you're probably using swift 3 locally if you encounter this (or..... swift 2 ? because it's quite a subject of programmer discussion, design and coding:: https://github.com/apple/swift-evolution/pull/659 https://developer.apple.com/documentation/swift/initialization_with_literals

However this EXACT behavior thats intended to discourage code smells is part of the same design document for the new "sequel" to the old API. `

We do not propose that every formatting feature Swift supports should be accessed by adding labeled parameters to initializers. But we believe that feeding interpolated values through an initializer on an associated type is a good primitive for formatting features. For instance, [here's a sketch of a formatting DSL][formatsketch] compatible with this proposal which lets you say things like:

Everyone gets tripped up on this one seems like. You need to select the name in Tag using dot-notation.

func description() -> String {
        return "\(title) by \(author). Filed under \(tag.name)"
    }